Methods for delivery of flows of objects over broadcast/multicast enabled networks

ABSTRACT

Content (e.g., multimedia streams, audio-video streams, video files, text, etc.) may be delivered to receiver devices over a broadcast channel and/or via a broadcast network via components (e.g., servers, receiver device, software applications, modules, processes, etc.) configured to communicate the content in a manner that reduces the amount of information communicated over the broadcast network, reduces the amount network bandwidth consumed by the communication, meets precise timing requirements for the individual objects that are communicated, and enables each receiver device to receive, decode, and render the content without consuming an excess amount of that receiver device&#39;s battery or processing resources.

RELATED APPLICATIONS

This application is a continuation of, and claims the benefit ofpriority to, U.S. Non-Provisional patent application Ser. No. 14/249,499entitled “Methods for Delivery of Flows of Objects overBroadcast/Multicast Enabled Networks” filed Apr. 10, 2014 which claimsthe benefit of priority to each of U.S. Provisional Application No.61/811,693, entitled “Methods for Delivery of Flows of Objects overBroadcast/Multicast Enabled Networks” filed Apr. 12, 2013; U.S.Provisional Application No. 61/818,912, entitled “Methods for Deliveryof Flows of Objects over Broadcast/Multicast Enabled Networks” filed May2, 2013; U.S. Provisional Application No. 61/878,368, entitled “Methodsfor Delivery of Flows of Objects over Broadcast/Multicast EnabledNetworks” filed Sep. 16, 2013; and U.S. Provisional Application No.61/912,145, entitled “Methods for Delivery of Flows of Objects overBroadcast/Multicast Enabled Networks” filed Dec. 5, 2013, the entirecontents of all five of which are hereby incorporated by reference.

BACKGROUND

Wireless communication technologies have seen explosive growth over thepast several years. Wireless service providers now offer their customersan array of services, and provide users with unprecedented levels ofaccess to information, resources, and communications. A recent additionto wireless communication services has been the ability to broadcasttelevision and other content to receiver devices. Multimedia forwardlink only (FLO) broadcast services allow users to view multimediaprogramming, such as television shows, as well as receive mobileeditions of news, entertainment, sports, business, Internet data, datafiles and other content, using a mobile receiver device configured toreceive the mobile broadcast transmissions. Multimedia broadcastservices represent significant bandwidth that may be used for deliveringa variety of services to receiver devices.

One protocol for delivering broadcast services is File Delivery overUnidirectional Transport (FLUTE), which is defined in InternetEngineering Task Force (IETF) Request for Comments (RFC) 3926 and RFC6726. FLUTE may be used for the delivery of large and small files tomany hosts, using delivery sessions of several seconds or more. Forinstance, FLUTE could be used for the delivery of large software updatesto many hosts simultaneously. FLUTE could also be used for continuous,but segmented, data such as time-lined text for subtitling—potentiallyleveraging its layering inheritance from Asynchronous Layered Coding(ALC, as specified in IETF RFC 3450 and IETF RFC 5775) and LayeredCoding Transport (LCT, as specified in IETF RFC 3451 and IETF RFC 5651)to scale the richness of the session to the congestion status of thenetwork. FLUTE is also suitable for the basic transport of metadata, forexample Session Description Protocol (SDP) files that enable userapplications to access multimedia sessions. FLUTE can be used with bothmulticast and unicast delivery, but its primary application is forunidirectional multicast file delivery.

There has been a recent trend to deliver streams, e.g., video and/oraudio streams, over unidirectional multicast systems as a sequence offiles. For example, the primary streaming delivery mechanism in the 3GPPMBMS system has evolved over the past couple of years from RTP deliveryof streams to delivery using FLUTE of DASH (MPEG Dynamic AdaptiveStreaming over HTTP, as specified in ISO/IEC 23009-1 and the 3GPPversion of DASH specified in TS26.247) formatted streaming content,where typically equal length durations of streaming content areformatted as DASH segment files and then each DASH segment file isdelivered as an object using the FLUTE protocol. However, FLUTE was notspecifically designed for such streaming applications, and thus hascertain limitations in this context.

SUMMARY

The various aspects include methods of transmitting information via abroadcast network by associating a collection of related source objectswith a source flow, and transmitting source objects in the collection ofrelated source objects associated with the source flow over thebroadcast network so that the source objects may be received andrecovered by a receiver device based on their relationship to eachother. In an aspect, the method may include determining a source flowidentifier for the source flow, and including the source flow identifierin a packet that may include data of at least one source object in thecollection of related source objects associated with the source flow.

In a further aspect, the method may include using a byte range in thepacket to identify data in the packet. In a further aspect, the methodmay include including a byte range in the packet that identifies data ofa source object in the packet. In a further aspect, the method mayinclude using a transmission session identifier (TSI) field of thepacket as the source flow identifier. In a further aspect, including thesource flow identifier in the packet may involve including the sourceflow identifier in a TSI field of the packet. In a further aspect, themethod may include using a combination of an Internet protocol (IP)destination address field and a user datagram protocol (UDP) port numberfield of the packet as the source flow identifier. In a further aspect,including the source flow identifier in the packet may include includingthe source flow identifier in a combination of an Internet protocol (IP)destination address field and a UDP port number field.

In a further aspect, the method may include using a codepoint (CP) fieldof the packet as the source flow identifier. In a further aspect,including the source flow identifier in the packet may include includingthe source flow identifier in a codepoint (CP) field of a data packet.In a further aspect, transmitting the collection of related sourceobjects may include transmitting a plurality of collections of relatedsource objects, each collection being associated with one of a pluralityof different source flows, each of the plurality of different sourceflows including a unique source flow identifier. In this aspect,including the source flow identifier in the packet that may include dataof at least one source object in the collection of related sourceobjects associated with the source flow may include including the uniquesource flow identifier of the source flow in the packet that may includedata of that source object.

In a further aspect, transmitting the collection of related sourceobjects may include transmitting at least one packet that may includeFEC repair data, a repair flow identifier, and a repair objectidentifier, the method further including associating a repair flow withone or more of the plurality of different source flows, determining therepair flow identifier for the repair flow, determining a collection ofrepair object identifiers for the repair flow, and determining, based atleast in part on a combination of the repair flow identifier and therepair object identifier of a packet, from which of the source objectsfrom the associated plurality of source flows the FEC repair dataincluded in the packet is generated.

In a further aspect, the repair flow identifier is included in a TSIfield. In a further aspect, the repair flow identifier is included inthe combination of an Internet protocol (IP) destination address fieldand a UDP port number field. In a further aspect, the repair flowidentifier is included in a codepoint (CP) field. In a further aspect,the repair object identifier is a transmission object identifier (TOI).

In a further aspect, the repair object identifier is an object sequencenumber (OSN). In a further aspect, transmitting at least one packet thatmay include FEC repair data may include transmitting at least one packetthat may include FEC repair data in the same time interval as the packetthat may include data for a corresponding source object. In a furtheraspect, the method may include generating FEC repair data for packetshaving the same repair flow identifier and same repair object identifierfrom two source objects in different source flows so that an amount ofdata received in combination from the packets having the same repairflow identifier and same repair object identifier and from packetscontaining data for either of the two source objects that is greaterthan or equal to an aggregate size of the two source objects issufficient to decode the two source objects. In a further aspect,portions of the repair flow identifier are included in different datafields of the packet that may include FEC repair data.

In a further aspect, the method may include determining a repair flowdeclaration for the repair flow so that the repair flow declaration mayinclude information suitable for signaling a relationship between therepair object identifier in the packet that may include FEC repair dataand the source objects from the collection of related source objectsassociated with source flows from which the FEC repair data in thepacket is generated. In a further aspect, the method may include using atemplate to signal the relationship via the repair flow declaration. Ina further aspect, a portion of the repair flow declaration istransmitted to the receiver device in advance of at least one sourceobject associated with the source flow associated with the repair flow.

In a further aspect, the method may include determining a source objectidentifier for each source object in the collection of related sourceobjects, and including the source object identifier in one or morepackets that include data for the source objects. In a further aspect,the method may include using a combination of the source flow identifierand the source object identifier to identify a corresponding sourceobject in the collection of related source objects. In a further aspect,including the source object identifier in the packet that may includedata may include including the source object identifier in the packet sothat a combination of the source flow identifier and the source objectidentifier identifies a corresponding source object for which the packetcarries data. In a further aspect, the method may include using a TOI asthe source object identifier.

In a further aspect, the method may include using an OSN as the sourceobject identifier. In a further aspect, the method may includetransmitting FEC repair data for the collection of related sourceobjects associated with the source flow over the broadcast network sothat the source objects can be received and recovered by the receiverdevice based on their relationship to each other, in which each packetthat may include FEC repair data for one or more of related sourceobjects associated with the source flow may include the source flowidentifier identifying the source flow for which the packet may includeFEC repair data, in which each packet that may include FEC repair datafor one or more of the related source objects associated with the sourceflow carries one or more source object identifiers of one or more sourceobjects from which the FEC repair data carried in the packet isgenerated, and in which a combination of the source flow identifier andone or more source object identifiers identifies one or more sourceobjects from the collection of related source objects associated withthe source flow from which the FEC repair data carried in the packet isgenerated.

In a further aspect, the method may include transmitting packetscarrying FEC repair data generated from the one or more source objectsin the same interval of time as packets carrying data for the one ormore source objects. In a further aspect, transmitting the sourceobjects in the collection of related source objects associated with thesource flow over the broadcast network may include transmitting thesource objects independent of their corresponding repair objects. In afurther aspect, the method may include using session descriptionprotocol (SDP) information to distinguish a source object from itscorresponding repair object.

In a further aspect, at least one source object in the collection ofrelated source objects may include a byte range of a file. In a furtheraspect, a uniform resource locator (URL) is associated with the file,the method further including identifying the at least one source objectvia the URL and the byte range. In a further aspect, at least one sourceobject in the collection of related source objects is a file. In afurther aspect, a URL is associated with the file, the method furtherincluding identifying the at least one source object via the URL. In afurther aspect, at least one source object in the collection of relatedsource objects may include a hypertext transfer protocol (HTTP) headerand a byte range of a file. In a further aspect at least some of thesource objects may include an HTTP header, an associated file, and anHTTP trailer.

In a further aspect, the method may include determining a source flowdeclaration for a collection of source objects associated with thesource flow so that the source flow declaration may include informationsuitable for signaling relationships between a location, name,availability time, or other metadata for the collection of sourceobjects associated with the source flow. In a further aspect,transmitting the collection of related source objects may includetransmitting the collection of related source objects via multimediabroadcast multicast services (MBMS). In a further aspect, transmittingthe collection of related source objects may include transmitting thecollection of related source objects via file delivery overunidirectional transport (FLUTE). In a further aspect, transmitting thecollection of related source objects may include transmitting the sourceobjects without transmitting forward error correction (FEC) signalinginformation. In a further aspect, at least some of the source objectsinclude an HTTP header and a byte range of a file.

The various aspects also include methods of transmitting one or moresource objects over a broadcast network, including receiving portions ofan entire file, generating source objects based on the received portionsprior to receiving the entire file, and transmitting the generatedsource objects to a receiver device prior to receiving the entire file.In an aspect, transmitting the generated source objects to the receiverdevice prior to receiving the entire file may include transmitting datafor the generated source objects in a different order than a data orderof the entire file. In a further aspect, receiving portions of theentire file may include receiving portions of a file that may include afile size at the beginning of the file, and in which data of a sourceobject is transmitted in an order such that at least some data of thefile after the file size is transmitted before the file size.

In a further aspect, a source object may include an HTTP header and anassociated file. In a further aspect, a source object may include anHTTP header, an associated file, and an HTTP trailer. In a furtheraspect, the method may include determining a source flow declaration fora collection of source objects associated with a source flow, in whichthe source flow declaration signals relationships between a location,name, availability time, or other metadata for the collection of sourceobjects associated with the source flow. In a further aspect, the methodmay include using a template to signal relationship information in thesource flow declaration.

In a further aspect, the method may include transmitting portions of thesource flow declaration for the source flow to the receiver device inadvance of at least one related source object associated with the sourceflow. In a further aspect, transmitting portions of the source flowdeclaration for the source flow to the receiver device in advance of atleast one related source object associated with the source flow mayinclude transmitting a portion that may include at least one of timinginformation, uniform resource identifier (URI), and informationidentifying decryption keys for source objects. In a further aspect,transmitting portions of the source flow declaration for the source flowto the receiver device in advance of at least one related source objectassociated with the source flow may include sending a portion of thesource flow declaration out-of-band to the receiver device in advance oftransmitting at least one source object associated with the source flow,and sending another portion of the source flow declaration in-band witha source object.

In a further aspect, sending another portion of the source flowdeclaration in-band with the source object may include sending anindication of a last portion of the data for the source object. In afurther aspect, providing portions of the source flow declaration to thereceiver device may include sending portions of the source flowdeclaration via a unidirectional transport protocol without sending afile delivery table. In a further aspect, transmitting the generatedsource objects to the receiver device prior to receiving the entire filemay include transmitting a collection of related source objects viamultimedia broadcast multicast services (MBMS). In a further aspect,transmitting the generated source objects to the receiver device priorto receiving the entire file may include transmitting a collection ofrelated source objects via file delivery over unidirectional transport(FLUTE).

In a further aspect, transmitting a collection of related source objectsmay include transmitting the source objects independent of theircorresponding repair objects. In a further aspect, the method mayinclude using session description protocol (SDP) information todistinguish a source object from its corresponding repair object. In afurther aspect, transmitting the generated source objects to thereceiver device prior to receiving the entire file may includetransmitting the source objects without transmitting FEC signalinginformation.

In a further aspect, the method may include performing FEC operations toprotect portions of an individual source object. In a further aspect,the method may include transmitting the individual source object withmultiple FEC encodings. In a further aspect, the method may includeadding a TOI or OSN for a protected portion of a source object in arepair packet header, and adding a byte range of the protected portionat an end of its transport source block. In a further aspect, the methodmay include adding source symbols at the beginning of a portion of asource object to be protected, and adding a byte range of a protectedportion in a repair packet header.

In a further aspect, the method may include adding a starting positionof a byte range of a protected portion of a source object and a numberof symbols that are covered by the byte range within a repair packetheader, and adding a size of the protected portion in bytes or octets atan end of a transport source block. In a further aspect, transmittingthe generated source objects to the receiver device prior to receivingthe entire file may include delivering a source object to the receiverdevice via a unidirectional protocol as a combination of an HTTP entityheader and an HTTP entity body so that the source object is suitable foruse in the receiver device as a regularly delivered HTTP resource.

Further aspects may include a communication system including atransmitter and a computing device configured with processor-executableinstructions to perform various operations corresponding to the methodsdiscussed above.

Further aspects may include a communication system having various meansfor performing functions corresponding to the method operationsdiscussed above.

Further aspects may include a non-transitory computer-readable storagemedium having stored thereon processor-executable instructionsconfigured to cause a computing device in a communication system toperform various operations corresponding to the method operationsdiscussed above.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and constitutepart of this specification, illustrate exemplary embodiments of theinvention, and together with the general description given above and thedetailed description given below, serve to explain the features of theinvention.

FIG. 1 is a block diagram illustrating a mobile multimedia communicationsystem suitable for use in various embodiments.

FIG. 2 is a stack diagram illustrating information flows through thevarious hardware and software protocol layers and modules that may beused by the various embodiments.

FIG. 3 is a block diagram illustrating various logical and functionalcomponents of an example broadcast communication system suitable fordelivering multimedia content to mobile receiver devices so that eachobject is associated with a flow in accordance with various embodiments.

FIG. 4 is a block diagram illustrating a source object that is packagedinto a plurality of source packets in accordance with an embodiment.

FIG. 5 is a block diagram illustrating differences between a currentFLUTE object and an embodiment FLUTE object.

FIG. 6 is an illustration of an embodiment FLUTE object that includes anHTTP header field and an availability time field.

FIG. 7A is an illustration of embodiment transport objects that includea source object field, a padding field, and a size/length (F) field.

FIG. 7B is an illustration of embodiment transport objects that includea source object field, a padding field, and a byte range field.

FIGS. 8A and 8B are block diagrams illustrating differences betweencurrent FLUTE repair forward error correction (FEC) Payload IDs andvarious embodiment repair FEC Payload IDs.

FIGS. 9A and 9B are block diagrams illustrating data-fields incommunication packets suitable for use in performing forward errorcorrection (FEC) for a synchronized source flows in accordance with anembodiment.

FIG. 10 is a block diagram illustrating data-fields of a communicationpacket suitable for use in performing forward error correction (FEC)operations for two synchronized source flows in accordance with anembodiment.

FIG. 11 is a block diagram illustrating data-fields of a communicationpacket suitable for use in performing forward error correction (FEC)operations for two unsynchronized source flows in accordance with anembodiment.

FIG. 12 is a block diagram illustrating data-fields of a communicationpacket suitable for use in performing forward error correction (FEC) forthree unsynchronized short source flows in accordance with anembodiment.

FIG. 13A is a process flow diagram illustrating an embodiment servermethod of communicating information in a flow of objects over abroadcast or multicast network.

FIG. 13B is a process flow diagram illustrating an embodiment receiverdevice method of receiving information in a flow of objects over abroadcast or multicast network and determining if the entire sourceobject has been received or if a portion of the object is missing fromthe received source packets.

FIGS. 14A and 14B are block diagrams that illustrate various logical andfunctional components of broadcast communication systems that aresuitable for communicating content in accordance with variousembodiments.

FIG. 15 is a block diagram illustrating various structures, data-fields,communication packets, transformations and information flows in anembodiment FEC Framework configured to generate a forward errorcorrection (FEC) repair packet based on two source objects.

FIG. 16 is a system block diagram of a receiver device suitable for usewith any of the embodiments.

FIG. 17 is a system block of a server computer suitable for use with anyof the embodiments.

DETAILED DESCRIPTION

The various embodiments will be described in detail with reference tothe accompanying drawings. Wherever possible, the same reference numberswill be used throughout the drawings to refer to the same or like parts.References made to particular examples and implementations are forillustrative purposes, and are not intended to limit the scope of theinvention or the claims.

In overview, the various embodiments may provide systems, devices,methods and non-transitory computer-readable media storing software forefficiently delivering content (e.g., multimedia streams, audio-videostreams, video files, text, etc.) to receiver devices over a broadcastchannel and/or via a broadcast network. The various embodiments mayprovide a number of features, enhancements, improvements, and benefitsover existing broadcast solutions.

For example, embodiments may include components (e.g., servers, receiverdevices, software applications, modules, processes, etc.) configured tocommunicate content to receiver devices in a manner that reduces theamount of information communicated over the broadcast network, reducesthe amount network bandwidth consumed by the communication, meetsprecise timing requirements for the individual objects that arecommunicated, and enables each receiver device to receive, decode, andrender the content without consuming an excess amount of that receiverdevice's battery or processing resources.

Embodiments may also include components configured to transmit a flow ofrelated objects (or a collection or a group of related objects) viaFLUTE and/or over a broadcast network in a single flow, stream, orcommunication channel so that they may be received, decoded, andprocessed by a receiver device based on their relationship to eachother.

Embodiments may include components configured to send signalinginformation (e.g., information pertaining to channel setup, security,content delivery, etc.) to coordinate how the content is to be deliveredover a broadcast system so as to reduce the amount of information thatis communicated over the network and the amount of information that isreceived, decoded, and error corrected by the receiver device whenrendering content.

Embodiments may include components configured to send object informationto receiver devices (e.g., FLUTE receivers) in advance of when thesource objects are sent to the receiver devices and/or in advance ofwhen the source objects are received by the receiver devices.

Embodiments may include components configured to broadcast samples orobjects as the information becomes available to them, and achieve veryprecise timing for each sample/object while remaining compatible withexisting FLUTE-based solutions and systems, thereby achieving ahybrid/combination of the functionality provided by existingpacket-based streaming systems and those provided by existing broadcastobject-based streaming systems.

Embodiments may include components configured to accomplish FLUTE-basedcommunications without using a file delivery table (FDT). In anembodiment, the components may be configured to communicate objects viaFLUTE and/or over a broadcast network without broadcasting an FDTobject, and without requiring a receiver device to receive two objectsfor every real object (e.g., source object) that is requested orrendered.

Embodiments may include components configured to deliver objects viaFLUTE and/or over a broadcast network so that the object delivery iswell aligned with the functions, operations, or requirements of existingDASH systems. In an embodiment, the components may be configured todeliver DASH content via flow object delivery mechanisms over abroadcast delivery network by broadcasting source objects so that theyare compatible with, or so that they may be interpreted as, DASHsegments of a DASH representation. In an embodiment, the components maybe configured to signal that the FLUTE-based objects are DASH segments,and package FLUTE-based objects so that a receiver device may receiveand process the FLUTE-based objects as if they were DASH segments.

Embodiments may include components configured to generate, broadcast, orreceive signaling information in an object or format that includes acombination of the features/characteristics provided by existingFLUTE-based objects and DASH-based segments.

Embodiments may include components configured to perform chunk deliveryoperations and/or chunk reception operations.

Embodiments may include components configured to communicate variablesized source packets where the size is arbitrarily determined by thesender.

Embodiments may include components configured to perform forward errorcorrection (FEC) object bundling operations.

Embodiments may include components configured to deliver source objectsindependent of their corresponding repair objects (e.g., FEC object).The components may distinguish source flows from repair flows viainformation carried in-band within data packets and/or via their SessionDescription Protocol (SDP) information.

Embodiments may include components configured to communicate sourcecontent that does not include FEC semantics (e.g., FEC Encoding ID,“no-code FEC” semantic, etc.), deliver the source content without FECsemantics, and/or deliver the source content without signaling the FEC(i.e., sending FEC signaling information). This allows receiver devicesthat are not equipped with FEC capabilities to receive, decode, andrecover the source objects via FLUTE and/or over a broadcast network.

Embodiments may include components configured to perform FEC operationsto protect portions of an individual source object or DASH segment toenable a source object to be delivered with multiple FEC encodings, andenable an object to be rendered before the entire object has beenreceived in the receiver device.

Embodiments may include components configured to package and communicatethe signaling and object information for source objects so that portionsof the object may be associated with different labels. The componentsmay be configured to use a Layered Coding Transport (LCT) codepointfield to identify a “type” of content that is carried in that packet(i.e., packets containing the original source objects).

Embodiments may include components configured to signal or identify theportions of a source object that are FEC protected using byte ranges.

Embodiments may include components configured to deliver and protect asource object based on a subset of a full source file/object, uniformresource locator (URL), or uniform resource identifier (URI).

Embodiments may include components configured to add transmission objectidentifier (TOI)/object sequence number (OSN) values for a protectedportion of a source object in a repair packet header (e.g., in a headerextension) and a byte range of the protected portion of the source blockat the end of the transport source block. The components may also beconfigured to add or start source symbols at the beginning of a portionof the source object to be protected (instead of at the very beginningof the source object), and provide an actual byte range of the protectedportion of the file, delivery, or source object within the repair packetheader directly. The components may also be configured to add a startingposition of the byte range and a number of symbols that are covered bythe byte range within the repair packet header directly, and add a sizeof the portion of the protected source object in bytes (or, equivalentlyin this disclosure, octets) at the end of the transport source block(e.g., FEC Encoding Object). The components may also be configured togenerate repair packets having a repair packet header for each protectedportion of a source object that includes a source object transmissionobject identifier (TOI) or object sequence number (OSN), a start byteposition within source object, and an end byte position within sourceobject.

Embodiments may include components configured to perform object deliveryoperations so as to enable a source object to include a complete HTTPresponse. The components may also be configured to send an HTTP entitybody and header (e.g., as a delivery object) so as to allow to the dataassociated with an object (or a byte range of an object) to bedistributed dynamically.

Embodiments may include components configured to begin sending dataahead of time, before the entire file or object is received or generatedin the server or sending device.

Embodiments may include components configured to send portions of afile/object out of order, before all the portions are received orgenerated, and/or independent of an FEC scheme. In an embodiment, thismay be accomplished via LCT mechanisms by utilizing the extensioncapabilities of LCT.

Embodiments may include components configured to use templates andtemplating techniques to signal relationships between the locations,names, availability times, and other metadata associated with acollection or sequence of objects to be delivered. In an embodiment, thecomponents may be configured to use a source flow declaration toidentify URIs for an object, and determine when the object will betransmitted and/or received over a broadcast/multicast channel. In anembodiment, the components may be configured to send a one-time staticFile Delivery Descriptor to the receiver devices, and use header fieldsin a dynamic delivery protocol to create dynamic information, suchinformation identifying a valid uniform resource identifier (URI).

Embodiments may include components configured to perform any or all ofthe above-mentioned operations while complying with the requirements ofthe current FLUTE standards and/or while maintaining backwardscompatibility with other components that implement the current FLUTEstandards.

The word “exemplary” is used herein to mean “serving as an example,instance, or illustration.” Any implementation described herein as“exemplary” is not necessarily to be construed as preferred oradvantageous over other implementations.

The term “receiver device” is used herein refer to any one or all ofcellular telephones, smartphones, multi-media players, personal dataassistants (PDA's), computing devices, server computers, personalcomputers, laptop computers, smartbooks, ultrabooks, tablet computers,palm-top computers, wireless electronic mail receivers, multimediaInternet enabled cellular telephones, wireless gaming controllers, andsimilar electronic devices that include communications circuitry forsending and receiving information, a memory, and a programmableprocessor.

The term “broadcast” is used herein to mean the transmission of data(multimedia streams, files, information packets, etc.) so that it can bereceived by a large number of receiving devices simultaneously, andencompasses unicast, multicast and other transmission technologiessuitable for sending information to one or many receiver devices in asingle transmission. Since broadcast networks can only transmit and haveno direct return communication link, such networks are also referred toherein as “forward link only” (FLO) broadcast networks to distinguishsuch communication networks from two-way wireless communicationnetworks, such as cellular telephone systems and wireless wide-areanetworks (e.g., WiFi, WiMAX, etc.).

The terms “delivery object” and “source object” may be usedinterchangeably herein to describe any self-contained unit that includesor is expressed as metadata or data, and which may be communicated usingwireless or broadcast communication technologies. Examples of sourceobjects include a file, an HTTP entity, a byte range, an entity headerand entity body containing the full file indicated by the entity header,an entity header indicating a byte range of a file, and entity bodycontaining the portion of the file indicated by the entity header, etc.

As used in this application, the terms “component,” “module,” “system,”“service,” “encoder,” “sender,” “receiver,” and the like are intended toinclude a computer-related entity, such as, but not limited to,hardware, firmware, a combination of hardware and software, software, orsoftware in execution, which are configured to perform particularoperations or functions. For example, a component may be, but is notlimited to, a process running on a processor, a processor, an object, anexecutable, a thread of execution, a program, and/or a computer. By wayof illustration, both an application running on a computing device andthe computing device may be referred to as a component. One or morecomponents may reside within a process and/or thread of execution and acomponent may be localized on one processor or distributed between twoor more processors. In addition, these components may execute fromvarious non-transitory computer-readable media having variousinstructions and/or data structures stored thereon. Components maycommunicate by way of local and/or remote processes, function orprocedure calls, electronic signals, communication messages, datapackets, memory read/writes, and other known network, computer,processor, and/or process related communication methodologies.

A number of different broadcast services, standards, and technologiesare available or contemplated in the future, all of which may implementand benefit from the various embodiments. Such services, standards andtechnologies include, e.g., multimedia broadcast/multicast service(MBMS), enhanced multimedia broadcast/multicast service (eMBMS),enhanced multi-broadcast service (EMBS), global broadcast service (GBS),open mobile alliance mobile broadcast services enabler suite (OMABCAST), MediaFLO®, digital video broadcast Internet protocol datacasting(DVB-IPDC), digital video broadcasting-handheld (DVB-H), digital videobroadcasting-satellite services to handhelds (DVB-SH), digital videobroadcasting-handheld 2 (DVB-H2), advanced television systemscommittee-mobile/handheld (ATSC-M/H), China multimedia mobilebroadcasting (CMMB), advanced television systems committee terrestrial(ATSC-T) and MPEG Media Transport (MMT). Each of these broadcaststandards, services, and technologies include, for example, broadcastcommunication channels suitable for communicating data, signaling,and/or content messages.

In addition to the broadcast services mentioned above, multimedia andother services may be delivered directly to individual mobile receiverdevices via various cellular and wireless communication services andstandards, any or all of which may implement and benefit from thevarious embodiments. Such services and standards include, e.g., thirdgeneration partnership project (3GPP), long term evolution (LTE)systems, third generation wireless mobile communication technology (3G),fourth generation wireless mobile communication technology (4G), globalsystem for mobile communications (GSM), universal mobiletelecommunications system (UNITS), 3GSM, general packet radio service(GPRS), code division multiple access (CDMA) systems (e.g., cdmaOne,CDMA1020™), enhanced data rates for GSM evolution (EDGE), advancedmobile phone system (AMPS), digital AMPS (IS-136/TDMA), evolution-dataoptimized (EV-DO), digital enhanced cordless telecommunications (DECT),Worldwide Interoperability for Microwave Access (WiMAX), wireless localarea network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), andintegrated digital enhanced network (iden). Each of these technologiesinvolves, for example, the transmission and reception of voice, data,signaling, and/or content messages.

It should be understood that any references to terminology and/ortechnical details related to an individual standard or technology arefor illustrative purposes only, and are not intended to limit the scopeof the claims to a particular communication system or technology unlessspecifically recited in the claim language.

Generally, the operations of receiving, decoding and displaying contenton a receiver device consumes a significant amount of the receiverdevice's available resources (CPU operations, battery power, memory,etc.). This is due, in part, to the large amount of digital informationthat must be received, decoded, and error corrected by the receiverdevice. The various embodiments may reduce the amount of informationthat must be received, decoded, and error corrected by the receiverdevice when receiving or rendering content.

There are currently a number of readily available compression techniques(e.g., moving picture experts group “MPEG” compression) that reduce theamount of information that must be communicated over the network whendelivering multimedia content. However, regardless of the efficiency ofthe compression method used by such techniques, a large volume ofinformation must be communicated over the network to provide users witha satisfying user experience. Thus, existing compression techniquesalone do not adequately reduce the amount of information communicatedover the network or considerably improve the performance or powerconsumption characteristics of receiver devices.

Often, there are network fluctuations (e.g., changes in the availabilityof resources) that cause the status of a delivery network to change overtime. These fluctuations may cause the receiver device to drop packets,under-run buffers, or otherwise negatively impact the user experience.Various technologies, such as DASH, allow a client application (e.g.,media player, etc.) of a receiver device to respond to such changes innetwork conditions by adjusting the bitrate or quality of the streamsthat are transmitted to or received by the receiver device. Thesetechnologies typically include a content generation server that reads ina raw video file and generates multiple versions of the file (called“representations”) for delivery over a generative Internet Protocol (IP)network.

DASH is a web-compatible international standard for describingmulti-rate encoded multimedia that allows client applications (e.g.,media players, etc.) to dynamically choose which portions of a mediapresentation to receive based on network dynamics, resource availabilityand/or other suitable factors. DASH supports partitioning eachrepresentation into segments that encode the data that is to bedelivered to the receiver device. DASH typically utilizes a MediaPresentation Description (MPD), which is a segment availability timelinethat announces the segments, the times that the segments are available,and indications of the playback rate of the media comprising thesegments. In current systems, the MPDs are provided to receiver devicesvia Over-the-Air (OTA) delivery technologies.

FLUTE is a transport layer technology/protocol for the unidirectionaldelivery of files that is particularly well suited for use withbroadcast/multicast delivery networks. A FLUTE solution or system mayinclude servers and receiver devices that implement the communicationmechanisms defined in Internet Engineering Task Force (IETF) Request forComments (RFC) 3926 and RFC 6726.

Existing FLUTE solutions deliver source objects (e.g., files, segments,etc.) independent of each other, and generally do not supportestablishing a relationship between related source objects that areincluded in the same flow. As a result, using existing solutions, aserver in the broadcast network must independently signal (i.e.,transmit a communication message that includes signaling or controlinformation) each object's parameters, the location at which the objectshould be stored, when the object is going to be delivered, and othersimilar information to the receiver device in advance of or during thesource object's delivery. According to the FLUTE standards (RFC 3926 andRFC 6726), a server must send such signaling information for each sourceobject that is to be delivered to that receiver device. Yet,communicating such signaling information for each object consumes anexcessive amount of the network's available bandwidth and requires thatthe receiver device perform additional processing, synchronization, ormemory access operations, any of which may reduce the performance and/orpower consumption characteristics of the receiver device or degrade theuser experience. In addition, if any of the signaling information islost then the object generally cannot be recovered.

The various embodiments may include methods, and devices and systemsconfigured to implement the methods, for managing communications in abroadcast network so as to reduce the amount of information that iscommunicated when delivering a flow of content or source objects.

The various embodiments may provide a delivery framework suitable fortransmitting a flow of related objects (or a collection of relatedgroups of objects) via FLUTE and/or over a broadcast network in a singleflow, stream, or communication channel such that they may be received,decoded, and processed based on their relationship to each other. Thisis in contrast to existing FLUTE-based solutions that do not identifyrelationships between FLUTE objects in a flow, package unrelated objectsinto the same flow, and require that the receiving device receiveindependent signaling information and data to decode each FLUTE object.

The various embodiments may also include network broadcast serversconfigured to send signaling information (e.g., information pertainingto channel setup, security, content delivery, etc.) to coordinate howcontent is to be delivered over a broadcast system in a manner thatreduces the amount of information that is communicated over the network.

Existing solutions for accomplishing object delivery via a broadcastsystem generally require that a server in the broadcast network sendsignaling information independently for each object that is to becommunicated over the broadcast network. This is due, in part, to theinability of existing solutions to adequately establish or identify arelationship between two or more objects communicated over the broadcastnetwork and/or within a flow or communication channel. For these andother reasons, existing solutions typically send the signalinginformation in a separate file/object than the file/object that includescontent information. In FLUTE-based systems, such signaling informationis typically included in a file delivery table (FDT), which describesvarious attributes associated with files that are to be delivered withina file delivery session.

Existing FLUTE solutions send file delivery tables (FDTs) to receiverdevices in objects that are separate from the objects that include thecontents they describe. Thus, using existing FLUTE solutions, a receiverdevice is required to receive two objects (e.g., a segment of video andan FDT that describes that segment of video) for every source object(e.g., segment of video) that is requested or rendered. Further, becausethe receiver device will not be able to recover or decode theinformation included in the source object (e.g., segment of video) ifthe packet/object that includes the FDT is lost or dropped, existingFLUTE solutions typically broadcast each FDT object multiple times toincrease the probability of its reception. Such redundant broadcastingof the FDT object is an inefficient use of broadcast resources that mayconsume an excessive amount of the network's available bandwidth, andhas other disadvantages, such as longer start-up delays when tuning intoa service.

The various embodiments may include components configured to communicateobjects (e.g., segments of video, etc.) via FLUTE and/or over abroadcast network without broadcasting an FDT object and withoutrequiring a receiver device to receive two objects for every real object(i.e., source object) that is requested or rendered. In an embodiment,at least a portion of the signaling information and object informationmay be communicated together in-band and/or in a single stream orchannel. Communicating such information in-band may reduce the amount ofinformation that is communicated over the network and is a moreefficient use of network resources.

Various embodiments may include a network server configured to sendobject information to receiver devices (e.g., FLUTE receivers) inadvance of when the source objects are sent to the receiver devicesand/or in advance of when the source objects are received by thereceiver devices. Such object information may include timinginformation, URIs specifying the name and location of files (e.g., wherethey are going to be referenced or accessed by an application), whichkeys to use to decrypt objects in case the objects are deliveredencrypted, and other identifying information relating to the sourceobjects that are to be delivered. Such object information for a relatedsequence of objects (or collection of objects) may be provided incompressed form. In an embodiment, portions of the object informationmay be sent out-of-band to receiver devices in advance of the sourceobjects, and portions of the object information may be sent in-band withthe source objects, without broadcasting any FDTs. In this manner, thevarious embodiments may completely eliminate the need to use FDTs inFLUTE-based communications.

Various embodiments may include network servers configured to packageand communicate the signaling and object information for source objectsso as to allow a receiver device to make more intelligent decisions andbetter plan for the reception of the source objects. This may beaccomplished by a server sending a receiver device informationpertaining to the objects that are going to be sent to the receiverdevice, before those objects are transmitted and/or before those objectsare received in the receiver device. Having access to such informationin advance facilitates better decision making and planning by thereceiver device.

Various embodiments may include components configured to link theobjects being delivered via FLUTE over a broadcast network to one ormore client applications of the receiver device.

Various embodiments may include components configured to deliver objectsvia FLUTE and/or over a broadcast network so that the object delivery iswell aligned with the functions, operations, or requirements of existingDASH systems.

Various embodiments may include components (e.g., servers in a broadcastnetwork, etc.) configured to deliver DASH content via flow objectdelivery mechanisms over a broadcast delivery network. In an embodiment,this may be accomplished by broadcasting source objects so that they arecompatible with, or may be interpreted as, DASH segments of a DASHrepresentation.

Various embodiments may include network servers configured to signalthat the FLUTE-based objects are DASH segments, and package FLUTE-basedobjects so that a receiver device may receive and process theFLUTE-based objects as if they were DASH segments.

Various embodiments may include components configured to generate,broadcast, or receive signaling information in an object or format thatincludes a combination of the features/characteristics provided byexisting FLUTE-based objects and DASH-based segments.

Various embodiments may include components configured to perform chunkdelivery operations and/or chunk reception operations. Such chunkdelivery operations may allow a server in the broadcast network to startsending an object before it is fully generated by a source encoderand/or an encapsulation unit or module. For example, a server in thebroadcast network may send an object that is to include 10 seconds ofvideo without waiting the full 10 seconds for the content to becomeavailable. That is, rather than waiting the full 10 seconds for thecontent to become available, the server may perform chunk deliveryoperations to start sending the first part of the video before the otherparts are received by the server. In an embodiment, the server may sendthe encapsulated version of an access unit or a network abstractionlayer unit or a sample as a separate source packet in order to minimizethe sending delay. Similarly, a receiver device may perform chunkreception operations to begin receiving, decoding, and using objectsbefore the entire source object is received in the receiver device. Forexample, a receiver device may be configured to perform chunk receptionoperations to start playing portions of a video content before theentire object that contains the video is received in the receiverdevice.

Various embodiments may include components configured to supportvariable sized source packets. That is, existing FLUTE standards andsolutions require that each source package and each repair package bethe same size (or at least a multiple of a predetermined symbol size).In contrast to the existing FLUTE standards and solutions, the variousembodiments may include components configured to generate, send,receive, decode, or use variable size source packets. The boundaries ofthe content carried in such variable size packets may be set completelyarbitrarily and/or may be aligned with the underlying structure of thecontent, e.g., with an access unit/module or network abstraction layerunit/module structure of video content. The use of such variable sizepackets is particularly advantageous when the source packet boundariesmay be aligned with the symbol structure (e.g., when using FEC, etc.).Also the loss of such a packet may only affect a single accessunit/module instead of multiple units/modules, and suitably configuredreceiver devices may generate a partially received object that can beprocessed by the receiver device (or software applications of thereceiver device) to render the received content and provide a gracefullydegraded quality.

Various embodiments may include components configured to performoperations suitable for communicating source content that does notinclude FEC semantics. That is, existing FLUTE standards and solutionsgenerally require that source delivery operations be signaled andperformed such that they are intimately tied to an FEC code and FECscheme used for recovery operations. This includes but is not limited tothe use of source symbols of a fixed size, requiring that all sourcepackets except for the last packet be a multiple of the source symbolsize, the use of source symbols as an elementary unit for applying FEC,etc. For these and other reasons, existing solutions require the use ofa “no-code FEC” semantic even in circumstances in which no FEC code issupported, required or used. However, receiver devices that are notequipped with FEC capabilities may not be able to receive, decode, orrecover objects that include FEC semantics.

Various embodiments may include servers configured to deliver sourcecontent without FEC semantics (and/or without signaling the FEC) so thatreceiver devices that are not equipped with FEC capabilities mayreceive, decode, and recover the source objects. In an embodiment, theserver may be configured to deliver content information in a firstobject and the FEC signaling information in a second object. In anembodiment, the first and second object may be delivered together,in-band.

Various embodiments may include components configured to perform forwarderror correction (FEC) object bundling operations. Various embodimentsmay include components configured to provide FEC protection overmultiple objects. In an embodiment, this may be accomplished (or madepossible) via a combination of the FEC object bundling operations andthe operations that separate the delivery of the FEC semantics from thesource content.

Various embodiments may include components configured to perform forwarderror correction (FEC) operations to protect portions of an individualsource object or DASH segment, enabling a source object to be deliveredwith multiple FEC encodings, providing greater flexibility and enablingan object to be rendered or “play-out” before the entire object has beenreceived. In such embodiments, FEC protection may be provided over apartial object, over a byte range of an independent source object,and/or over combinations of byte ranges from different source objects indifferent streams. For example, a component may be configured to provideindependent FEC protection over the first three (3) frames of a sourceobject, independent FEC protection over the next five (5) frames of thesource object, another independent FEC protection over the next six (6)frames of the source object, and yet another independent FEC protectionover the last ten frames of the source object. This manner of FECprotection may allow the system to better support the transmission ofvariable sized source packets or objects, allow a receiver device tobegin decoding objects incrementally before the entire object isreceived, allow for the transmission of larger objects, reduce thenumber or frequency of independent refresh frames included in theobject/stream, improve the latencies associated with streaming content(especially content comprised of large objects), reduce the amount ofbandwidth consumed by the stream, and provide more flexibility andcontrol over the granularity over which the system is able to provideFEC protection.

Various embodiments may include components configured to package andcommunicate the signaling and object information for source objects sothat portions of the object may be associated with different labels. Forexample, a beginning portion of an object may be labeled as “Type A,”followed by a portion labeled as “Type B,” follow by another portionlabeled as “Type A.” This may allow a video layer component (e.g., avideo layer decoder, etc.) to identify, categorize, or classify variousparts or portions of an object that are the same type, related,independently playable, etc. The object labels may also enable otherapplications of information that may be useful to the video layercomponent. In an embodiment, the labeling information for the variousparts/portions of a source object may be communicated or signaled to areceiver device via a code point that defines, includes, or specifiesvarious properties.

Various embodiments may include components configured to signal oridentify the portions of a source object that are FEC protected usingbyte ranges. These components may also be configured to label thepackets that contain the byte ranges of FEC protected portions with atype identifier or data-field. The type identification of portions of asource object (which is typically of value to higher level applicationsconsuming the source objects once they are recovered at the receiver)can be used in conjunction with the system to provide FEC protectionover various byte ranges to be able to provide FEC protection ofportions of source objects of different types. This allows each portionof a source object that corresponds to a type of data within a sourceobject to be independently recovered using FEC, which may be of value tothe consuming application when different portions of a source objectcorresponding to a type are of use to that application even when otherportions of the source object are not yet available due to not yetarriving at the receiver, or will never be available due to insufficientFEC protection. However, the FEC protection of portions of sourceobjects and the identification of different portions of the sourceobjects as being of different types can be used independently of oneanother. For example, FEC protection may be provided over twoconsecutive portions of a source object of different types, or FECprotection may be provided over portions of a source object that is notaligned with the different portions of different types, or FECprotection may be provided over different portions of a source objectthat is not classified into types.

In various embodiments, the delivery and protection of a source objectmay be based on a subset of a full source file. For example, in anembodiment, a component may be configured to treat a certain byte rangeas a separate delivery object (or source object). The signalinginformation associated with this byte range may be communicated,transmitted, or signaled via metadata, such as dynamic metadata (DMD).For example, an object in dynamic metadata may be assigned aContent-Range header that allows the system to associate an object witha Content-Range of a URL that is defined in a Content-Location field ofthe metadata. In this case as an extension to FLUTE there may not be aone-to-one mapping between a transmission object identifier (TOI) and aURL, but the TOI may be mapped to a combination of a URL and a byterange. In an embodiment, the source object may be divided into multipleprotection objects or FEC protected portions.

Various embodiments may include components configured to addtransmission object identifier (TOI)/object sequence number (OSN) valuesfor a protected portion of a source object in a repair packet header(e.g., in a header extension) and a byte range of the protected portionof the source block at the end of the transport source block. Otherembodiments may include components configured to add or start the sourcesymbols at the beginning of a portion of the source object to beprotected (instead of at the very beginning of the source object), andprovide an actual byte range of the protected portion of the file,delivery, or source object within the repair packet header directly. Ina further embodiment, a component may be configured to add the startingposition of the byte range and a number of symbols that are covered bythe byte range within the repair packet header directly, and add thesize of the portion of the protected source object in bytes (or octets)at the end of the transport source block (e.g., FEC Encoding Object).This preferred embodiment requires fewer repair packet header bytes thanthe embodiment discussed above, does not waste repair symbols, and doesnot have padding bytes in the first symbol of the transport sourceblock.

Various embodiments may include components configured to generate repairpackets having a repair packet header for each protected portion of asource object that includes the following: source object TOI (or OSN), astart byte position within source object, and an end byte positionwithin source object. In an embodiment, the repair packet header may be10 bytes (e.g., two bytes for TOI, four bytes for a start byte position,and four bytes for an end byte position) for each protected portion of asource object. In an embodiment, these and other mappings may beincluded in a metadata file that is delivered to a receiver device in aseparate file or object. In a preferred embodiment, a component may beconfigured to signal the start byte position and the size of the objectin symbols. In an embodiment, the TOI may be mapped via the metadata. Inan embodiment, the protected object size in bytes may be included in asource block (e.g., FEC Encoding Object) at a position that is known orsignaled by the receiver. In an embodiment, a component may beconfigured to apply FEC protection to a portion of a source object,starting at its start byte position. Various embodiments may definemultiple extension headers that enable the system to signal differenttypes of sizes, such as the size in symbols, the start address (e.g., 16bits, 32 bits) of the delivery/source object and the size in symbols,etc.

Various embodiments may include components configured to use a LayeredCoding Transport (LCT) codepoint field to identify a “type” of contentthat is carried in that packet (i.e., packets containing the originalsource objects). In an embodiment, this information may be included inthe code point. In an embodiment, a component may be configured toidentify a relationship between the byte ranges of transport sourceobjects that are FEC protected and “types” of portions of the transportsource objects. For example, byte ranges of the transport source objectmight be labeled with one of several types (e.g., generically type X,type Y, type Z), and each source packet may be generated to include onlydata of one type. As a further example, a byte range 12,000 through19,999 of type X might be included in seven (7) source packets (eachlabeled as type X in a codepoint field), the first six (6) sourcepackets may include 1200 bytes and the seventh (7th) source packet mayinclude 800 bytes. All such information may be included in codepointfields of the associated packets. A codepoint field (or code point) maybe assigned a specific value if it is the start of a specific type.Furthermore, FEC protection may be provided over portions of sourceobjects that are consecutive within the source object of the same type.For example, there might an FEC repair object that protects the byterange 12,000 through 19,999 of a source object that corresponds to dataof type X within a source object as indicated in the code point.

Various embodiments may include components configured to use the sourceFEC Payload ID of an existing FEC scheme (i.e., instead of a byte rangeas proposed in the source protocol). This embodiment may enablesupporting backward compatibility with existing FEC schemes, forexample, on the source delivery level. This embodiment may also supportobject bundling. The Source FEC Payload ID could be converted to a byterange prior to applying the FEC framework. This embodiment may allowapplying the advanced FEC framework with arbitrary FEC schemes in thesource protocol.

In an embodiment, source objects may be (or include) byte ranges ofexisting files (e.g., with a URL that identifies them as for exampledefined in ISO/IEC 23009-1, Annex E), as opposed to the completeexisting files.

Generally, a web cache is a mechanism for the temporary storage of webdocuments (e.g., HTML, pages, images, etc.) to reduce bandwidth usage,server load, and network latency. Typically, a web cache stores copiesof documents passing through it so that subsequent web-based requestsmay be satisfied directly from the web cache. An HTTP cache is a webcache that implements the basic freshness, validation, and invalidationrequirements specified in the HTTP standards.

Various embodiments may include components configured to perform objectdelivery operations so as to enable a source object to include acomplete HTTP response. This may allow a receiver device to operate asan HTTP cache so that if another computing device issues an HTTPrequest, or an application running on the same device issues an HTTPrequest, the receiver device may provide it with a complete HTTPresponse as if it were being entirely delivered over HTTP.

Various embodiments may include components configured to perform any orall of the above-mentioned operations while complying with therequirements of the current FLUTE standards and/or while maintainingbackwards compatibility with other components that implement the currentFLUTE standards.

The various embodiments may be implemented within a variety ofcommunication systems, networks and/or mobile multi-media broadcastsystems, an example of which is illustrated in FIG. 1. Specifically,FIG. 1 illustrates a communication system in which mobile receiverdevices 102 may receive content from multimedia broadcast network 104,unicast network 106, or via the Internet 108. A typical multimediabroadcast network 104 includes a plurality of broadcast transmitters 112controlled by a mobile broadcast network control center/broadcastoperation center (BOC) 114. The multimedia broadcast network 104broadcasts content from the broadcast transmitters 112 as mobilebroadcast transmissions 113 for reception by the mobile receiver devices102. Within the BOC 114, there may be one or more servers 110 formanaging content broadcasts, and which provide a connection to theInternet 108.

In addition to the multimedia broadcast network 104, mobile receiverdevices 102 may communicate via a unicast network 106, such as acellular telephone network, WiFi network (not shown), WiMAX, etc. Atypical cellular telephone network includes a plurality of cellular basestations 116 coupled to a network operations center 118. The networkoperations center 118 operates to connect voice and data calls betweenmobile receiver devices 102 and other network destinations, such as viatelephone land lines (e.g., a POTS network, not shown) and the Internet108.

Communications between mobile receiver devices 102 and the unicastnetwork 106 may be accomplished via two-way wireless communication links115 such as LTE, 4G, 3G, CDMA, TDMA, and other cellular telephonecommunication technologies. Such two-way wireless communication links115 may enable users to stream multimedia content to receiver devices(e.g., mobile devices).

To facilitate Internet data communications (e.g., streaming videofeeds), the unicast network 106 will typically include one or moreservers 120 coupled to, or within, the network operations center 118that provide a connection to the Internet 108. Mobile receiver devices102 may further connect to the Internet 108 via a wired connection whenavailable, in which case the Internet 108 may serve as the unicastnetwork. Mobile receiver devices 102 may also receive non-broadcastcontent over the Internet 108 using well known conventional web-basedaccess protocols.

Generally, the operations for receiving and rendering content by areceiver device (e.g., the mobile receiver devices 102 discussed above)may be divided into separate and independent groups or categories ofoperations, and each group or category of operations may be assigned toa layer (e.g., physical layer, data link layer, etc.). In each of theselayers, various hardware and/or software components may implementfunctionality that is commensurate with responsibilities assigned tothat layer. For example, media streams (e.g., broadcast, point-to-point,etc.) are typically received in the physical layer, which may include aradio receiver, buffers, and processing components that perform theoperations of demodulating, recognizing symbols within the radiofrequency (RF) signal, and performing other operations for extractingraw data from the received RF signal.

FIG. 2 illustrates an example protocol stack 200 of a mobile receiverdevice suitable for receiving and displaying content in accordance anembodiment. In the illustrated example of FIG. 2, the protocol stack 200includes a physical layer 202 module, a data link layer 204 module, anetwork layer 206 module, a transport layer 208 module, and anapplication layer 210 module, each of which may be implemented inhardware, in software, or in a combination of hardware and software.Further, each of the modules 202-210 may include sub-layers, which mayalso be implemented in hardware, in software, or in a combination ofhardware and software.

The physical layer 202 module may include radio components configured toreceive the basic communication signal, extract data from thecommunication signal, and provide the data to a media transport stream(e.g., MPEG-2 Transport Stream) or a media access control module in thedata link layer 204 module. The data link layer 204 module may provideaddressing and channel access control mechanisms that make it possiblefor various components of the mobile receiver device to receive thedifferent streams of data. The data link layer 204 module may alsoinclude various sub-modules or sub-layers for carrying a packet protocol(e.g., Internet Protocol) on top of a Moving Picture Experts Group(MPEG) transport stream (TS), such as the illustrated multiprotocolencapsulation forward error correction (MPE-FEC) module/layer and theprogram and system information (SI/PSI) module/layer.

Portions of the stream/signal carrying the content and information flowsmay be passed by the data link layer 204 module to the network layer 206module, which may include an IP module/interface forcommunicating/relaying streams, datagrams and/or packets to thetransport layer 208 module. Streams and data received in the transportlayer 208 module may be delivered to the appropriate transport layersub-modules or sub-layers, which process and package the data fortransport. Such transport layer sub-modules/sub-layers may include auser datagram protocol (UDP) module/layer, an asynchronous layeredcoding/layered coding transport (ALC/LCT) module/layer, a real-timetransport protocol (RTP) module/layer, and a file delivery overunidirectional transport (FLUTE) module/layer. In an embodiment, the RTPmodule/layer may be included in or as part of the application layer 210,similar to DASH formats.

The application layer 210 module may include protocols and methodsrequired establish host-to-host, end-to-end connections and to conductprocess-to-process communications. The application layer 210 module mayalso include end-user applications (e.g., media player, etc.) forprocessing, rendering and/or displaying the received content on themobile receiver device. The application layer may also include mediaformats, such as DASH formats, encoded media streams and other mediarelated metadata. In the example illustrated in FIG. 2, the applicationlayer 210 module includes a DASH module, an RTP module, and a mediaplayer module.

FIG. 3A illustrates various logical and functional components of anembodiment broadcast communication system 300 suitable for deliveringmultimedia content to mobile receiver devices. In the exampleillustrated in FIG. 3A, the broadcast communication system 300 includesan advanced object forward error correction component 302, an advancedobject signaling component 304, and an advanced object deliverycomponent 306. Multimedia content is encoded in variable-size objects(Obj), which are broadcast via three different object flows (Object Flow1, 2 and 3). Each object flow (Object Flow 1, 2 and 3) includes or isassociated with an advanced object delivery component 306. Each of thevariable-size objects (Obj) may be a full object or a portion of anobject (e.g., a byte range, etc.).

In various embodiments, any or all of the advanced object forward errorcorrection component 302, advanced object signaling component 304, andadvanced object delivery component 306 may be implemented in hardware,software, or a combination of hardware and software.

The advanced object delivery component 306 may be configured to performvarious object delivery operations, including establishing oridentifying a flow-association between the objects (Obj) on a deliverylevel, adding timestamps to the objects or data on a packet level,performing chunked delivery operations, packetizing or fragmenting theobjects (Obj) into source packets, and performing various other similaroperations.

The advanced object signaling component 304 may be configured to performvarious signaling operations, such as packaging and sending signalinginformation in object flows (Object Flow 1, 2 and 3), accomplishing HTTPserver/proxy/cache replication, and delivering “availability timing”information for HTTP objects. For example, the advanced object signalingcomponent 304 may be configured to signal the availability timinginformation of an HTTP object when the corresponding object isdelivered. This allows the broadcast communication system 300 to performtime-out operations when delivering objects over broadcast. The deliveryof such availability timing information may also allow the broadcastcommunication system 300 to implement features similar to a cachetime-out policy in which the items that are stored in the cache are onlymade available to a computing system for a limited duration and/or aretimed-out after a certain duration or period of time. In this manner,the broadcast communication system 300 may ensure that the data, objects(Obj), and/or source packets are always current or include up-to-dateinformation.

The advanced object signaling component 304 may also be configured toprovide a receiver device with signaling information, which may includevarious information fields that identify when and how one or moreobjects (Obj) will be delivered to the receiver device. In variousembodiments, such information may be delivered to the receiver deviceover the broadcast session before the corresponding object or packetsare received by the receiver device or transmitted by the server.

The advanced object forward error correction component 302 may beconfigured to perform various error correction operations, includingoperations for: providing FEC protection for source flows of objects;providing FEC protection for bundles of objects; providing FECprotection for portions of individual objects; and allowing delivery ofsource objects independent of FEC semantics, codes, logic, support oroperations. In an embodiment, the advanced object forward errorcorrection component 302 may be configured to provide FEC protection forbundles of source objects while at the same time deliver the individualsource objects of the bundles independent of the FEC semantics.

In an embodiment, the advanced object forward error correction component302 may be configured to provide FEC protection for byte ranges (andcombinations of byte ranges) of transport source objects to protectportions of objects in the same or different flows or streams. Thisallows a receiver device to perform FEC decoding operations to render anobject incrementally as the object is received. This is in contrast toexisting solutions in which FEC encoding is performed over an entireobject and which generally require that a receiver device wait until anentire object is received before performing FEC decoding operations torender that object.

In an embodiment, the advanced object forward error correction component302 may be configured to provide FEC protection for flows of sourceobjects. The advanced object forward error correction component 302 mayprovide FEC protection over a flow of source objects in any object baseddelivery system, including FLUTE-based delivery systems. In addition,the advanced object forward error correction component 302, advancedobject signaling component 304, and/or advanced object deliverycomponent 306 may implement, or may be a subset of, existing FLUTEstandards and solutions. Further, any or all of these components 302,304, 306 may extend FLUTE functionality (e.g., functionality provided bythe FLUTE sub-layer discussed above with reference to FIG. 2, etc.) toallow streams or flows of objects to be delivered within the FLUTEcontext more efficiently and in compliance with the existing FLUTEstandards.

Existing broadcast object-based streaming delivery solutions, such asthat provided by current FLUTE solutions (specified in 3GPP MBMS fordelivery of DASH sequences of segments) lack many of the features andfunctionality provided by packet-based streaming solutions. As such,many existing streaming solutions are not object-based, but instead,packet-based solutions that deliver packet streams via RTP/IP, MPEG2transport stream (TS), or other similar technologies. When FEC is usedin such packet-based streaming solutions, the packets are typicallypartitioned into source blocks, and FEC repair protection is providedindividually for each of these source blocks. For this and otherreasons, existing packet-based streaming solutions lack the ability toname and identify (e.g., with a uniform resource identifier (URI))portions of the stream, and in general lack many of the advantageousfeatures that are provided by object-based streaming solutions, such asDASH.

In an embodiment, the broadcast communication system 300 may beconfigured to provide functionality that is a combination of thefunctionality provided by existing packet-based streaming systems andthose provided by existing broadcast object-based streaming systems.That is, in contrast to existing streaming solutions, the broadcastcommunication system 300 may achieve functionality that combines thefeatures of (and provides additional features beyond) existingpacket-based streaming solutions and broadcast object-based streamingsolutions, while remaining compatible with existing FLUTE-basedsolutions and systems, and while accomplishing such communications viabroadcast.

Generally, packet-based streaming systems can generate individualpackets to match the characteristics of the source content they carry,package, or encode. For example, when the source content is a videostream, a packet-based streaming system may generate each source packetto include one frame of video data or a slice or a network abstractionlayer unit. This allows the packet-based streaming system to send eachvideo frame or each slice or access unit or network abstraction layerunit immediately as it becomes available to the system, which may reducenetwork latency in some environments or networks. In addition,packet-based streaming systems typically achieve very precise timing foreach sample, which is also beneficial in some environments or networks.

Existing broadcast object-based streaming systems are better suited thanpacket-based streaming systems to deliver large samples or objects, butrequire that all of the information that is to be included in a segmentor object be made available for communication over an IP network beforethe segment/object is sent. That is, existing broadcast object-basedstreaming systems do not allow a server to begin sending content for asource object as it becomes available to that server. Rather, existingbroadcast object-based streaming systems require that the server waituntil all of the information for a DASH segment, or source object ingeneral, is received or available to the server before it can beginsending packets for that DASH segment (or source object) to receiverdevices. In addition, existing broadcast object-based streaming systemsare not well suited to meet precise timing requirements for individualsamples/segments/objects, and thus are susceptible to network latencyand jitter in some environments or networks.

The various embodiments may include a broadcast communication serverconfigured to efficiently broadcast samples or objects as informationbecomes available to the server and achieve very precise timing for eachsample/object while remaining compatible with existing FLUTE-basedsolutions and systems, thereby achieving a hybrid/combination of thefunctionality provided by existing packet-based streaming systems andthose provided by existing broadcast object-based streaming systems. Forexample, the broadcast communication server may be configured to includedata in a file as such data becomes available to the server, and beginbroadcasting the file immediately so that the data is made available tothe network as it becomes available to the server (i.e., before theserver receives all the data that is to be included in the file). Inaddition, the broadcast communication server may add timing informationto each file/packet at the FLUTE level. Such timing information may beused to measure jitter in the network and perform other similaroperations. Jitter measurement and jitter compensation may be used todimension buffers and to ensure low-latency operations.

Existing FLUTE systems use file delivery tables (FDTs) to communicatesignaling information. An FDT may include forward error correctionobject transmission information (FEC OTI), a uniform resource identifier(URI), a transmission object identifier (TOI) that identifies the objectinformation included in the packet, and a transmission session/streamidentifier (TSI) for the object.

A forward error correction object transmission information (FEC OTI) mayinclude a “FEC Encoding ID” that identifies a particular FEC codingmethodology. In addition, FEC OTI may include various parameters, suchas a byte range or object/file size (F), an alignment factor (Al) thatidentifies a byte offset, a symbol size (T), the number of source blocks(Z) in the object, and the number of sub-blocks (N) that each sourceblock is partitioned into for that object.

In the various embodiments, each object may include different forwarderror correction object transmission information (FEC OTI) and/or adifferent uniform resource identifiers (URIs). The file delivery table(FDT) may link the transmission object identifier (TOI) to otherinformation included in the FDT, such as the URI, FEC OTI, and otherobject transmission parameters. The transmission session/streamidentifier (TSI) may scope (i.e., identify and provide context for) theTOI, which allows multiple objects to be delivered in the same sessionand with different TOIs. The combination of the TSI and TOI may uniquelyidentify an object. An object sequence number (OSN) may be mapped to theTOI, and vice versa. The TSI may be mapped to the FLID.

A file delivery table (FDT) may include both static and dynamicinformation. For example, the transmission object identifiers (TOIs),URIs, content type and the byte range or object/file size (F) values mayinclude dynamic information that varies from object to object. Thevalues for the FEC Encoding ID, transmission session/stream identifier(TSI), alignment factor (Al), symbol size (T), number of source blocks(Z), and number of sub-blocks (N) may all include static informationthat is fixed across multiple objects or across a sequence of objects.Such values may be provided once for an entire sequence of relatedobjects (or a collection of objects), for example, by using the valuesZ=1, N=1, and fixed Al and FEC Encoding ID values for all the objects.However, using existing solutions, signaling information must betransmitted (via broadcasting an FDT) for each object that is to bebroadcast, irrespective of the number of static fields that are sharedacross multiple objects in the stream.

When delivering a stream of objects, the TOI and URI values may bepredicted across a stream of related objects, whereas the object/filesize (F) is typically not as predictable. The URI information may beconveyed via templating by using the TOI and a template to generate aURI.

In addition to the value fields discussed above, in the existingFLUTE-based solutions, each packet includes an FEC Payload ID. The FECPayload ID provides information about the packet payload, and mayinclude a source block number (SBN) and an encoding symbol identifier(ESI). The FEC Payload ID may include information that is specific to aparticular FEC methodology or system, irrespective of whether the packetincludes source data or repair data. For this reasons, the FEC EncodingID is required by existing systems when delivering source data for anobject via FLUTE.

The various embodiments may include broadcast servers configured todeliver source data for an object via FLUTE without including FECsemantics, such as an FEC Encoding ID data-field or value. The variousembodiments also may include receiver devices configured to receive,decode, and use objects that do not include the FEC semantics.

Existing FLUTE solutions do not support establishing a relationshipbetween multiple objects that are included in a single object flow orcommutation channel. Using existing solutions, all of the static anddynamic information that may be included in an FDT for an object must bedelivered to the receiver device individually for each object. Inaddition, at least one FDT generally must be delivered for each objectin a stream, as some of the information delivered within an FDT for anobject is typically only available when the object itself is delivered.This information must be delivered within an FDT for each object,irrespective of whether there are actual or potential changes to theinformation, and irrespective of whether the same information may beused for multiple objects or across all objects in a stream. Inaddition, the FEC Payload ID, which is an FEC semantic and providesinformation about the contents of each packet delivered with the object,is typically FEC specific and not required in all instances. Repeatedlybroadcasting the same information, information that is not required orused by the receiver device, or information that could be shared acrossmultiple objects, as is done in existing systems, is an inefficient useof network resources.

The various embodiments may include a broadcast communication serverconfigured to broadcast related objects in a single flow, stream, orcommunication channel so that signaling information (e.g., FDTparameters) may be shared across multiple objects in the flow. Thisreduces the amount of information that is communicated over the network,is a more efficient use of network resources (e.g., bandwidth, etc.),and is more reliable than existing solutions for delivering informationto receiver devices.

The various embodiments may also include a broadcast communicationserver configured to broadcast a sequence of related objects. In anembodiment, the relationships between the objects may be identified viathe TOI field, which may be achieved by splitting the TOI field into twosub-fields: a Flow ID (FLID) sub-field that identifies a flow of relatedobjects; and an object sequence number (OSN) sub-field that identifieseach source object within the flow of related source objects. In anembodiment, the OSN may be mapped to a TOI field. The TOI may be splitin this manner because the FLUTE standards do not define a rigidstructure for the TOI field, and thus each number contained therein maybe used for a different object or field. Further, since existing TOIfields typically store four (4) bytes of information, the TOI fields maybe split into a one (1) byte FLID parameter sub-field and a three (3)byte OSN parameter sub-field without impacting their backwardcompatibility with existing systems.

In an embodiment, the FLID may be a one (1) byte parameter, which allowsthe system to support 256 different FLIDs for each session. In anembodiment, the zero (0) value may be excluded as an acceptable orsupported value for the FLID sub-field so as to avoid confusion with aTOI value of zero (0), which may be reserved for FDT object delivery insome systems.

In an embodiment, the TOI may be a 4-byte value, and a value range(e.g., 128-255, etc.) may be reserved for use for the FLID sub-field ofthe TOI to allow delivery of objects using existing FLUTE solutions andwithin the same session. For example, solutions that do not split theTOI into sub-fields and use an FDT may restrict the used TOI values tothe range 0 through 128*256*256*256−1=2147483647 (first use case). Onthe other hand, solutions that split the 4-byte TOI into a 1-byte FLIDand a 3-byte OSN may restrict the used FLID values to the range 128 to255 (second use case) without any further restriction on the range of3-byte OSN values. When concatenated, the 1-byte FLID and the 3-byte OSNform a 4-byte TOI integer value that ranges from 128*256*256*256 to256*256*256*256−1 (or equivalently the TOI integer value ranges from2147483648 through 4294967295). This ensures that the overall range ofthe 4-byte TOI values used for the two use cases discussed above isdisjoint. This allows the FLUTE broadcast delivery system to deliver, inthe same session, objects that do not split the TOI and use FDTs (firstuse case described above, existing FLUTE solution) and objects thatsplit the TOI and do not use FDTs (second use case described above). Asdescribed, this may be achieved by partitioning the range of overall TOIvalues into non-intersecting ranges for the two different use cases,which eliminates the possibility of conflicting TOIs for the two usecases in the same session.

In an embodiment, the transmission session/stream identifier (TSI) maybe used as the Flow ID (FLID).

A flow of related objects, such as that identified by the FLID sub-fieldof the various embodiments, may correspond to a stream of video segmentsin a DASH representation. For example, each object delivered in such arepresentation would have the same FLID (e.g., FLID=1), and thus packetsthat have the same FLID may be treated by the various embodiment serversand receiver devices as objects belonging to the same flow of objects.Another flow may for example be the audio data of a DASH MediaPresentation.

Objects that belong to the same flow of objects, and thus have the sameFLID value, may be identified via the OSN sub-field. The OSN sub-fieldmay store a simple integer, starting at a value of zero (0) for thefirst object and incremented by one (1) for each subsequent sourceobject in the flow. In an embodiment, the OSN may be a three (3) byteparameter, which at an object delivery rate of one object per second,allows for roughly 200 days of distinct OSN values.

The TSI may scope the FLID sub-field, which may scope the OSN sub-field.That is, the TSI value may provide sufficient context fordifferentiating between two objects having the same the FLID value, andthe FLID value may provide sufficient context for differentiatingbetween two objects having the same OSN value.

In an embodiment, the system may be configured to use the TSI as theFLID value. In various embodiments, the TSI field may be mapped to aDASH representation and vice versa.

By splitting the TOI field into two sub-fields (i.e., FLID and OSN) inaccordance with the various embodiments, the broadcast network does notneed to broadcast FDTs for the source flows. Instead, the broadcastnetwork may broadcast a single source flow declaration (which may beincluded in the FLUTE metadata) for each receiver and for each flow(i.e., not for each object in the flow).

A source flow declaration may be a succinct representation of variousinformation fields and values relating to an object flow and/or theobjects of packets included in the object flow. The source flowdeclaration may identify the relationships between the object sequencenumbers and objects. The source flow declaration may declare a flow atthe metadata level. This may be achieved by including the variousinformation fields and value in FLUTE metadata. The source flowdeclaration may include a unique flow identifier (FLID) that identifiesthe source packets in the flow and other static information for thatflow. The source flow declaration may also include information relatedto the type of flow (e.g., video object flow, audio object flow, etc.).The source flow declaration may identify the Multipurpose Internet MailExtensions (MIME) type of the objects in the flow and include othersimilar information. In an embodiment, the source flow declaration mayinclude an indication of a decryption key and/or a sequence ofdecryption keys suitable for use in decrypting objects in the flow(i.e., if they are encrypted).

The source flow declaration may be carried in the user servicedescription (USD) in the case of MBMS delivery using FLUTE. The sourceflow declaration may communicate the signaling information that is mostrelevant to a FLUTE receiver or receiver device. The source flowdeclaration may provide receiver devices with out-of-band in-advanceinformation relevant to flows of objects delivery.

In an embodiment, a source flow declaration may be declared orrepresented in a server or receiver device as follows:

flow_declaration{ flow_type = source FLID = 5 source_type = video }

In the above example of a flow declaration, the type of flow isindicated by the value of the flow_type data-field, in this case“source”, the flow identifier for this flow is indicated by the value ofthe FLID data-field, in this case “5”, and the type of content carriedin the objects of the flow is indicated by the value of the source_typedata-field, in this case “video”. In general, the flow_type and the FLIDare required to be declared within a flow_declaration, whereas otherinformation may or may not be included in the flow_declaration.

As an alternative, existing fields may be used to signal and supportusing a Flow Identifier (FLID), in which case the Transport ObjectIdentifier (TOI) signaling and usage can be used to identify thetransport object, instead of a separately defined OSN, without othermodifications to the signaling or protocols. For example, the existingcodepoint field in the LCT header can be used to signal the FLID (inaddition to the other usages of the codepoint field), and the existingTOI field can be left unmodified to signal the transport objectidentifier, instead of using a newly defined OSN.

The various embodiments may include a broadcast server configured topackage source objects into source packets such that the source packets:do not include any dependencies on FECs or FEC semantics, do enablechunk delivery, do enable sending objects before they are fullyavailable, and do support packaging the source objects into variablesize packets (e.g., delivery of each access unit of the underlyingmedia).

In an embodiment, the source_type data-field or value may be replaced bythe MIME type of the corresponding object flow.

In an embodiment, the source packets may be generated to include aSource Payload ID data-field and value that includes a byte offset ofthe first source object byte carried in the packet. The source packetsmay also be generated such that the bytes of a source object are storedsequentially within packet, and so that an ending byte position may beinferred by size of packet payload. In an embodiment, the Source PayloadID may be a four (4) byte parameter. In an embodiment, to improve FECrecovery efficiency, the broadcast system may align the number of bytesin each source packet with size of FEC symbols. In an embodiment, thesource packet may be generated to also include a code point, which mayinclude labeling information and/or FEC coding information for byteranges or portions of a source object.

By packaging the source objects into source packets in this manner, thevarious embodiments may allow for the delivery of the source objectsindependent of the FEC operations or semantics. Further, by packagingthe source objects so that they are independent of the FEC operations,the sender may apply different FEC methodologies to the same sourceobject when needed.

In addition, by packaging the source objects so that they areindependent of the FEC operations, the various embodiments may allow thesender (i.e., a server) to apply FEC protection methodologies to producea repair flow that protects a source flow or combinations of flows tocreate a first version of the FEC protection, wherein each FEC encodingis applied over multiple objects of the flow or combinations of flowssuitable for delivery to receivers in bad receiving conditions or forreceivers that only record the broadcast session and thus want thehighest fidelity recovery possible, and another repair flow thatprotects the same flow or combinations of flows to create a secondversion of FEC protection, wherein each FEC encoding is applied overfewer objects of the flow or combinations of flows that the firstversion, which can provide shorter end-to-end latency suitable fordelivery to all other receivers and/or which allow for faster access tothe media stream when joining the session. For example, the firstversion of FEC protection may be a first repair flow where each FECencoding is applied to a pair of consecutive source objects from asource flow, and the second version of the FEC protection may be asecond repair flow where each FEC encoding is applied to a single sourceobject from the same source flow.

The various embodiment broadcast systems may be configured to provide anumber of source object signaling enhancements. Existing systems use FECsemantics to determine if/when all the packets of a source object havebeen received and/or the length/size of the source object. The variousembodiments may allow a receiver device to determine if or when all thepackets of the source object have been received, the length/size of thesource object, and if the source object is a incomplete object (e.g.,not all the packets have been received), all without using or requiringthe packets to include FEC semantics. In an embodiment, this may beachieved by signaling to indicate the end of a source object by settinga “close object flag” (e.g., B-flag) in the last source packet of asource object, wherein the B-flag is an existing field in the existingFLUTE standard.

For example, the value of the B-flag field may be set to zero (0) in allbut the last source packet, in which the B-flag may be set to one (1).This is possible because the FLUTE standards do not set definitive orprecise requirements for the use of the B-flag field, and in any case,do not specify that it is to be set to one (1) in only the last sourcepacket of a source object.

The last source packet (P) of a source object contains the last portionof the source object. Thus, by setting the B-flag in only the lastsource packet (i.e., setting the B-flag of P=1), the various embodimentsmay enable a receiver device to determine if the last portion of asource object has been received. Further, the receiver device maydetermine the size/length of the source object by setting thelength/size value to be equal to a byte offset in the source Payload IDof the last source packet (P) plus the payload size of the last sourcepacket (P). Further, the receiver device may determine if any otherportions of the object have not been received using the byte offset andpayload size of other source packets received for the object, i.e., thereceiver may determine if there are any sequences of bytes of the objectthat have not been received within source packets. In this manner, thebroadcast systems may determine if or when all the packets of the sourceobject have been received, determine the length/size of the sourceobject, and/or determine if the source object is a incomplete object,all without requiring an FDT or other signaling information to be sentfor each object and without including FEC semantics in the sourcepackets or objects.

FIG. 4 illustrates that an embodiment source object 402 packaged into aplurality of source packets 404-410 such that the broadcast systems maydetermine if or when all the packets of the source object have beenreceived without an FDT or FEC semantics. Each source packet 404-410includes a B-Flag field, a Source Payload ID field, and a Source Payloadfield. In the example illustrated in FIG. 4, the source object 402 is5,000 bytes in size/length and each of the first three source packets404-408 includes a Source Payload data-field that is 1280 bytes insize/length. Since the size of source object (i.e., 5,000 bytes) is nota multiple of 1280, the Source Payload data-field of the last packet 410includes only 1160 bytes. The B-flag field of each of the first threesource packets 404-408 is set to zero(0), whereas the B-flag field ofeach of the last packet 410 is set to 1.

In overview, a receiver device or receiver may determine if the entiresource object has been received, or if at least some portion of theobject is missing, from the received source packets. For example, if thereceiver doesn't receive the last packet of the object having a B-flagfield set to one (1), then the receiver may determine that at least somesuffix of the object has not yet been received. On the other hand, if asource packet having a B-flag field set to one (1) has been received forthe object, then the receiver may determine that it has received thesuffix of the object, and can determine the size of the object bycomputing the sum of the byte offset in the packet with the B-flag setto one (1) and the packet payload size of that packet. In addition, whena source packet having a B-flag field set to one (1) has been receivedfor the object, the receiver may determine whether there are internalportions of the source object missing from the byte offsets and packetpayload sizes of the received source packets.

With respect to the example illustrated in FIG. 4, a receiver device mayreceive source packets 404, 408 and 410 (and not source packet 406) anddetermine, from reception of source packet 410 with the B-flag set toone, that the suffix of the object has been received and that its sizeis 3840 (byte offset)+1160 (payload size)=5000 bytes in size. Thereceiver device may also determine from the received source packets, andthe byte offsets and payload sizes of those packets, that bytes1280-2559 of the object are missing (the bytes carried in the sourcepacket 406 that was not received). If instead of source packet 406, thereceiver did not receive source packet 410, then the receiver maydetermine that it has not yet received a source packet having a B-flagfield set to one (1) for this object, and thus that a suffix of theobject is not yet been received. In an embodiment, the receiver devicemay be configured to wait for a duration of time before determining thatthere is a high probability that no further packets not yet received fora source object were or will be transmitted or will be received, andperform recovery operations as needed. The amount of time that areceiver may wait to make this determination may be at least partiallybased on delivery time information, if any, in the source declaration.

In an embodiment, the broadcast system may be configured to generate thesource packets 404-410 to include timing information. This timinginformation may be the timing of the sending of the source packets. Thusthe timing of the source packets may be placed in the packetsthemselves. The inclusion of timing information in the source packetsallows the system to replicate RTP operations, measure network jitter,associate delivery timing, associate media time relationships, specify amask over a NTP timestamp, etc. For example, the system may generate a64 bit NTP timestamp and use a 4 byte mask of the 64 bit NTP timestampto include in the packets to determine the precision of the timing. Thetimestamp may present the time the packet is sent (or some otherreference) and may be associated with a presentation time (similar toRTP, but not used for media synchronization). The mask may be specifiedin the signaling information and may have any arbitrary range betweenbit 1 and 64. The mask sizes may be a multiple of 8 bits to enable bytebased time stamps. The mask size may also be signaled as zero (0) inorder to indicate the non-presence of timing information.

In an embodiment, the system may be configured to use the congestioncontrol information in the FLUTE/LCT header to carry timing information.Alternatively, the congestion control information in the FLUTE/LCTheader may be used to carry a flow sequence number to enable packet lossmeasurements per flow by the receiver device.

FIG. 5 illustrates some of the differences between a prior art FLUTEobject packet header 502 and an embodiment FLUTE object packet header504. Specifically, FIG. 5 illustrates that the embodiment FLUTE objectpacket header 504 may include a timestamp 506 field, a FLID 508 field, aOSN 510 field, and a byte offset 512.

The various embodiments may include components configured to accomplishchunk delivery and reception of source flows so that the end-to-endlatency of the data deliver is minimal. On the broadcast side, anembodiment broadcast server may send source objects in chunks as theybecome available because it only needs to put a byte offset into eachsource packet as it is sent. The broadcast server may also set a “closeobject flag” (B-flag) in the last source packet of a source object sothat the source object size is not needed to send source packets.Similarly, the server may set “close type” flag, field or value toidentify the last packet of each portion or different type of portion inthe source object. For example, if the source object is partitioned intofour different portions, and the first and third portions are labeled as“Type A,” the second and forth portions are labeled as “Type B,” thesystem may include or set a “close type” flag/field in the last packetof each of these four portions to identify that packet as being the lastpacket in that portion and/or of that type.

On the receiver side, a receiver device may be configured to recover asource object as it arrives in chunks. The receiver device may use thesource packet byte offset to determine the position of data withinsource object immediately send sequentially received source packet datato an application or client (e.g., media player). The receiver devicemay detect missing data within a source object via the source Payload IDbyte offset and “close object flag” (B-flag) field values. The receiverdevice may determine if there are missing data gaps via the byte offsetvalue and the size of the received source packet payloads. The receiverdevice may detect a missing suffix of data by determining that it hasnot yet received a source packet with B-flag set to one (1).

FIG. 6 is an illustration an embodiment FLUTE object 602 that includes(or is bundled with) an HTTP header 604 field and an availability times606 field. The HTTP header 604 field may include an HTTP response headerthat includes information suitable for use by an HTTP proxy to replicatethe caching behavior.

The availability times 606 field may include signaling or controlinformation pertaining to the availability timing of the FLUTE object602 at the receiving device, which may allow the system to determine ifthe FLUTE object 602 has been activated, is valid, or has expired. In anembodiment, the availability times 606 field may include Network TimeProtocol (NTP) time stamps for the start and/or end availability timesof object for use by a consuming application. The inclusion of suchtiming information in the FLUTE object 602 may allow the broadcastsystem to implement features similar to a cache time-out policy in whichthe items that are stored in the cache are only made available for alimited duration and/or are timed out after a certain period of time. Inthis manner, the broadcast system may ensure that the FLUTE object 602includes current or up-to-date information.

In existing FLUTE solutions, FDT objects that carry metadata informationfor the delivery of source objects do not include timing information orthe timestamps of their corresponding source objects. The FDT object mayinclude one or two fields typically included in an HTTP response header,but existing FDT objects do not allow for the inclusion of a completeHTTP header as is accomplished in the various embodiments. Further,since broadcasting an FDT object consumes additional bandwidth, andsince each FDT is typically broadcast repeatedly for each source objectin the flow, it is advantageous to minimize the size of the individualFDT objects. The various embodiments may accomplish object deliverywithout FDT objects, and deliver the HTTP response header and timestampinformation along with the source object, which is a more efficient useof network resources that reduces the amount of bandwidth consumed byeach object flow.

The various embodiments may include components configured to communicatesource flow declaration information that includes template information.As discussed above, a source flow declaration may be a succinctrepresentation of information fields relating to an object flow (e.g.,FLIDs, flow types, MIME types, decryption key information, etc.) andwhich may be used to identify the relationships between the objects in aflow of objects. By using templates and templating techniques, thevarious embodiments may use the source flow declaration to identify URIsfor object and when the objects are going to be transmitted and/orreceived over a broadcast/multicast channel. For example, a source flowdeclaration that includes template information may be represented in aserver or receiver device as follows:

flow_declararation{ flow_type = source FLID = 5 source_type = video URI= http://localhost.seq1/object%OSN% Timescale = 10 START_TRANSMISSION =%OSN*20% END_TRANSMISSION = %OSN*20 + 20% }

In the forgoing example, the URI field of the source flow declarationincludes the string “% OSN %.” Using templating techniques, this stringmay be converted into a different value for each object in the flow ofobject to provide an implicit mapping between the URIs and sequencenumbers of the objects. For example, the object with OSN=25 within thisflow is associated with the URI http://localhost.seq1/object25. Similartechniques may be used for the transmission information, such as for the“START_TRANSMISSION” field and the “END_TRANSMISSION” field. In anembodiment, the “START_TRANSMISSION” and “END_TRANSMISSION” fields maybe computed based on the value of the “Timescale” field to indicate thetiming of delivery. For example, Timescale=10 indicates that the timemeasurement is in units of 10 ticks per second, and thus the object withOSN=25 within this flow has a start transmission time of 50 seconds andan end transmission time of 52 seconds.

Thus, templates and templating techniques may be used to providemechanism to derive URI for object, delivery time for object,relationship between FLID, OSN and URI, etc. As such, templates may beused in the various embodiments as compact and succinct means ofsignaling the relationships between the locations, names, availabilitytimes, and other metadata associated with a sequence of objects to bedelivered.

The various embodiments may include components configured to communicatesource flow declaration information that includes template informationand a link to an application. Such a source flow declaration may berepresented in a server or receiver device as follows:

flow_declararation{ flow_type = source FLID = 5 source_type = videoMPD_URL = http://news.video_content/sept25.2012.mpd MPD_REP_ID =http://newsfeed.example.com/video500 URI =http://localhost.seq1/object%OSN% Timescale = 10 START_TRANSMISSION =%OSN*20% END_TRANSMISSION = %OSN*20 + 20% }

In the forgoing example, the source flow declaration includes a MPD_URLfield and a MPD_REP_ID field. In an embodiment, these fields may be usedby an embodiment server or receiver device for correspondence betweenobjects and DASH segments of a representation described in an MPD.

Various embodiments may include components configured to provide thebroadcast communication system with advanced FEC capabilities that allowthe source objects to be delivered independently, independent of the FECsemantics or information, without the use of FDTs, and while minimizingpacket header overheads, supporting chunk delivery of the objects, andallowing for the use of variable size source packets.

Various embodiments may include components configured to use static FileDelivery Information for signaling flow declarations.

The various embodiments may include components configured to providesupport for the bundled FEC protection of flows in an object context.

The various embodiments may communicate source objects and provide FECinformation only where needed, and not in source flow declarations orsource objects, and while enabling receiver devices that do not have FECcapabilities to ignore FEC repair flows.

The FEC may be symbol based with fixed symbol size per repair flow.

FEC repair flow may provide protection of objects in one or more sourceflows (e.g., via bundling).

The various embodiments may include various FEC specific components,elements, communication messages, and data structures, such as a FECrepair flow declaration, FEC repair packets, and a FEC transport object(which may include a source block or bundle of source objects). The FECrepair flow declaration may include FEC signaling information and otherFEC specific information. The FEC transport object may include a sourceobject and related information. Various embodiments may be configured toapply FEC encoding to one, or a concatenation of multiple, FEC transportobjects.

In an embodiment, a receiver device may be configured to recover bundledobjects from repair packets based on available FEC information.

The various embodiments may include a separate and unique FLID for eachrepair flow that is distinct from other source FLIDs and repair FLIDs.This FLID may be scoped by the TSI and may scope the informationincluded in the FLID.

Various embodiments may provide FEC repair for synchronized sourceflows, which may provide protection for source flows. The protectedsource flows may be listed in repair flow declaration. Variousembodiments may time align objects in the protected source flows,protect source objects with the same OSN from different source flows.The various embodiments may include one OSN in each repair flow packetso that the OSN for the repair matches the OSN of source objects forprotected source flows.

Various embodiments may also provide FEC repair for unsynchronizedsource flows to provide protection for source flows that include objectsthat are not completely time aligned. Various embodiments may protectsource objects with differing OSNs from different flows, protect morethan one source object of a single source flow, which may beaccomplished by listing these source flows as many times as sourceobjects to be protected.

The various embodiments may set the number of OSNs in repair flowpackets equal to number of objects protected. The OSNs may be listed inorder matching the source flow list in the repair flow declaration.

The various embodiments may include a FEC transport object for a sourceobject, which may be used for FEC encoding operations. The FEC transportobject may include a source object, padding bytes, and a size/length (F)field, where F is the size of the source object in bytes. In anembodiment, size/length (F) field may be a 4 byte field.

The various embodiments may include an FEC transport object for aportion of a source object, which may be used for FEC encodingoperations. The FEC transport object may include a byte range for thesource object and padding bytes. In an embodiment, the FEC transportobject may also include a size/length (F) field. In various embodiments,the size/length (F) field may provide a byte range of the source objector the difference in bytes between the end of the byte range and startof the byte range of the portion of source object.

The FEC transport object size may be a multiple of the symbol size T.The size/length (F) field value may be carried in the last 4 bytes ofthe FEC transport object. In this case, the number of symbols in the FECtransport object may be calculated as ceil((F+4)/T), where ceil(x) isthe function that returns the smallest integer that is at least as largeas x. For example, if T=1280 and F=5000 then the number of symbols inthe FEC transport object is calculated as ceil(5004/1280)=4. The FECtransport object may be generated to include a minimal number of paddingbytes. Padding bytes and F may not be sent within the source packets ofsource object, and may be part of FEC transport object that FEC decodingrecovers.

The various embodiments may include FEC repair flows for providing FECprotection to source flows, which may be used to protect a portion of asource object of a source flow, to protect individual objects of asource flow, to protect multiple objects from one or more source flows,or to protect multiple portions of objects from one or more sourceflows. When used for protecting individual objects in a source flow,each FEC encoding may be generated from the FEC transport object for asource object. When used for protecting multiple objects from one ormore source flows, each FEC encoding may be generated from aconcatenation of FEC transport objects for source objects. Theconcatenation may be in order of source flows indicated by a repair flowdeclaration and OSNs received in repair packets.

In various embodiments, the FEC transport object length may bedetermined at the receiver from a TOL carried in repair packets, whichindicates the number of symbols in the FEC transport objectcorresponding to the OSN carried in the repair packets and the FLIDdeclared in the repair flow declaration. The TOL may be a 2 byte valuethat is included in the repair FEC Payload ID for each FEC transportobject of a source object that is FEC protected.

Generally, the FEC decoder only needs to know the symbols for theportion of the object that it is to recover. As such, variousembodiments may set the FEC transport object length based on the symbolrange covered by a portion of the object that is FEC protected. That is,the FEC transport object length may be set based on the range of sourcesymbols that a portion of source object covers. For example, if thesymbol length is a 1000 bytes (i.e., a new symbol starts at everythousand bytes and the symbol zero covers bytes 0-999 of the sourceobject), and the portion of the source object that is to be FECprotected starts at byte 1500 and ends at byte 4500, then the system mayset the FEC transport object length to indicate the symbol range 1-4 tocover the byte range 1500-4500. The system may then pad the ranges1000-1499 and 4501-4999 in the FEC transport object with zeros. In anembodiment, the receiver device may automatically add this padding ofzeros when it decodes the object, and the receiver may add these symbolswhen it encodes the object. This eliminates the need to transmit thepadding information. This also reduces the number of bytes that areencompassed within the FEC encoding by removing padding bytes from theFEC protected portions.

To reduce the performance impact of partial symbols, in an embodiment,the system may be configured to select a symbol size that is smallenough so that the padding included in an FEC transport object is smallor not significant. In an embodiment, the system may be configured togenerate the packet structure to line up with the symbol boundaries.

FIG. 7A is an illustration of an embodiment transport object 700 for asource object. The illustrated transport object 700 includes a sourceobject 702 field, a padding 704 field, and a byte range or size/length(F) 706 field. The transport object 700 can be associated with aplurality of symbol boundaries 708, which may be determined based onsymbol size T. The number of the symbols into which the FEC transportobject may be partitioned may be calculated as the ceiling of the sum ofthe size/length of the source object 702 and the size of the byte rangeor size/length (F) 706 field divided by the symbol size (T). Thetransport object 700 may be created by populating the size/length (F)706 field and the source object 702 field. The padding 704 field may bepopulated to fill any gaps between the source object 702 field and thesize/length (F) 706 field.

In the example illustrated in FIG. 7A, the FEC transport object 700 ispartitioned into three symbols, and the source object 702 does not endat a symbol boundary 708. The transmission object length (TOL) is 3 inthis example, indicating that the FEC transport object is 3 symbols insize.

The repair FEC Payload ID may include an encoding symbol identifier(ESI) field and a transmission object length (TOL) field and symbols foreach protected object. In an embodiment, ESI and TOL fields may each betwo (2) bytes in size.

FIG. 7B is an illustration of an embodiment transport object 750 for aportion of source object. The illustrated transport object 750 includesa source object 702 field, a padding 704 field, and a byte range 752field. The transport object 750 may be associated with a plurality ofsymbol boundaries 754, which may be determined based on symbol size T(e.g., 1000) or based on the source object. The byte range 752 coveredby the FEC protected portion may be equal to 1500-4500, and thus thesymbol range of the protect portion may be equal to symbols 1-4 (i.e.,to cover the byte range 1500-4500), if the symbol size is set to 1000bytes as described in the example above.

The repair FEC Payload ID may include an ESI field and a symbol rangefield that covers the starting and ending boundaries 754 of the portionthat is FEC protected. In an embodiment, ESI and symbol range fields mayeach be two (2) bytes in size.

In an embodiment, the FEC Payload ID may include the source symbol startposition and source symbol end position. In a further embodiment, theFEC Payload ID may include a TOI of the source from the protected flowof the object identifier. The TOI may be two (2) bytes in size.

In a preferred embodiment, the FEC Payload ID includes the byte startposition within the source object of the portion to be protected,together with the size in symbols (rounded up to the nearest symbolboundary) of the FEC Encoding Object that includes the portion of thesource object that is to be protected, and the size in bytes (or octets)of the protected portion of the source object is carried at the end ofthis transport source block. This preferred embodiment is relativelyefficient in terms of repair header overheads, minimizes wastedprotection of padding bytes within the transport source object, andallows the receiver to FEC decode to recover the FEC Encoding Object andextract the portion of the source object from the information within therepair header and within the FEC Encoding Object.

FIG. 8A illustrates differences between a current FLUTE repair FECPayload ID 802 and various embodiment repair FEC Payload IDs 804, 806,808. The current FLUTE repair FEC Payload ID 802 includes an SBN fieldand an ESI field. Each of the embodiment repair FEC Payload IDs 804,806, 808 include an ESI field and one transmission object length field(TOL1, TOL2, TOL3, etc.) for each object that is protected by the FECencoding. Thus, the format of the embodiment repair FEC Payload IDs 804,806, 808 depends on the number of objects protected.

The current FLUTE repair FEC Payload ID 802 does not include informationidentifying the number of symbols in the source object or correspondingFEC transport object (FEC Encoding Object), nor any informationidentifying the length of the source object or corresponding FECtransport object. Instead, in the current FLUTE solutions, informationabout the source object and/or corresponding transport object is carriedin a separate FDT associated with that source object. The SBN (sourceblock number) field of the current FLUTE repair FEC Payload ID 802identifies the source block from which the symbols carried in the repairpacket are generated, which is useful when the object is partitionedinto multiple source blocks.

In an embodiment, the ESI field of the embodiment repair FEC Payload IDs804, 806, 808 may be replaced with a universal object symbol identifier(UOSI) field, which uniquely identifies how the repair symbols carriedin the repair packet payload are generated from the object. When thenumber of source blocks in the FEC Encoding Object is one, then the UOSIand the ESI are equivalent. However, when the number of source blocks Zof the FEC Encoding Object is more than one, then the UOSI value A for asymbol with ESI value B from the source block with SBN value C iscalculated as A=B*Z+C. Using a UOSI instead of an ESI is especiallyuseful if objects are at least sometimes partitioned and FEC encoded asmultiple source blocks.

FIG. 8B illustrates differences between a current FLUTE repair FECPayload ID 802 and various addition embodiment repair FEC Payload IDs852 a and 852 b. The FEC Payload IDs 852 a for a single (possiblypartial) source object includes a source object start byte position(SBP), a transmission object length (TOL), which is the size in symbolsof the transmission object, and an ESI field. FEC Payload IDs 852 b alsoincludes a TOI field. Similarly, the FEC Payload IDs 858 may include aSBP and a TOL for each TOI field corresponding to a portion of a sourceobject to be protected, followed by an ESI field.

In other embodiments, the FEC Payload ID includes a source object startbyte position (SBP) and a end byte position (EBP) for each (possiblypartial) source object protected by the repair flow, and an ESI field.The FEC Payload ID may also carry a TOI for each (possibly partial)source object protected by the repair flow.

When the number of source blocks Z in the FEC encoding object is greaterthan one (1), or when the number of sub-blocks per source block N isgreater than one (1), it is often important that the system maintain orachieve various properties, characteristics or objectives. For example,it may be important that system ensure that the source objects can besent independent of the FEC protection (as described in thisapplication). It may also be important that the system ensure that theFEC protection operations are effective and efficient (e.g., in terms ofthe recovery overhead) when recovering protected objects when there aredifferent amounts of loss of source packets from the different sourceobjects. In addition, it may also be important to for the system toensure that FEC decoding operations may be performed in the receiverdevice so that the FEC transport objects are recovered efficiently, withas little reordering of data as possible, and using as little memory aspossible. Yet, conventional and straightforward methods for forming theFEC Encoding Object are often inefficient or not adequate because theydo not allow the system to maintain or achieve these properties,characteristics or objectives.

The various embodiments may include methods, and components configuredto implement the methods, of forming the FEC Encoding Object so as toallow the system to maintain or achieve the properties, characteristicsor objectives discussed above when the number of source blocks Z isgreater than one (1) and/or when the number of sub-blocks per sourceblock N is greater than one (1). For example, a component may beconfigured to map portions of the FEC transport objects evenly (or asevenly as possible) amongst the source blocks. Then, within a sourceblock, the component may map the portions of the FEC transport objectsto the sub-blocks of that source block. For each such FEC transportobject, the component may fill the same number of sub-symbols of eachsub-block so that each FEC transport object fills a consecutive set ofsub-symbols within each sub-block.

As an example, suppose the number of FEC transport objects is 0, andthat the number of symbols in FEC transport object i is K_(i). Let Kt bethe sum from i=0 to O−1 of K₁, i.e., Kt is the total number of symbolsin all the FEC transport objects. For each j=0 to Z−1, let N_(i) be thenumber of source symbols assigned to source block j. In this example,the component may calculate the number of symbols per source block andthe sub-symbol size per sub-block using standard methods (e.g., thosedescribed in IETF RFC 6330). Then, for each object i=0 to O−1, thecomponent may partition the value of K_(i) amongst the Z source blocksso that K_(i,j) is the number of symbols of FEC transport object i to beassigned to source block j. This may be accomplished by going throughthe source blocks in a round robin fashion and assigning one symbol ofthe first object to each of the source blocks until all symbols of thefirst object have been assigned, and then continuing from that point inthe round robin and assigning one symbol of the second object to each ofthe source blocks until all symbols of the second object have beenassigned, etc. These operations (i.e., going through the source blocksin a round robin fashion, etc.) may be performed repeatedly until all Ktof the symbols of the objects have been assigned to the source blocks.The component may then assign portions of the FEC transport objects toeach of the source blocks of the FEC encoding object. This may beaccomplished by starting from the beginning of each FEC transportobject, where T is the symbol size: for i=0 to O−1, for j=0 to Z−1, thenext K_(i,j)*T bytes of object i are assigned to source block j. Thecomponent may then assign portions of the FEC transport objects assignedto each source block to the sub-blocks of the source block. For k=0 toN−1, let SS_(k) be the sub-symbol size in bytes for sub-block k. Then,the portion of FEC transport object i may assigned to sub-block k ofsource block j is SS_(k)*K_(i,j) bytes. By forming the FEC encodingobject in this manner, the component may allow the system to achieve ormaintain all the desirable properties, characteristics or objectivesdiscussed above.

Various embodiments may include components configured to generate or usea repair flow declaration. The repair flow declaration may includeinformation suitable for determining a protection type (synchronized orunsynchronized), for determining how to perform signaling operations forthe source flows, for determining the source objects to protect in thesource flows, and for determining the source flows that are to beprotected by the repair flow. The type of protection may be useful indetermining the header format of the packets. The repair flowdeclaration may also list the source flows that are protected by therepair flow such that they may be identified by their FLID. The repairflow declaration may also list the source flows so that the order oflisting corresponds to an order of concatenation of FEC transportobjects. In an embodiment the repair flow declaration may include FECOTI fields or values.

A repair flow declaration that protects a single synchronized sourceflow may be represented in a server or receiver device as follows:

flow_declaration{ flow_type = repair FLID = 20 repair_type =synchronized, source_FLIDs = 5 FEC Encoding ID = 6, Al = 8, T = 1280, Z= 1, N = 1

In the above example of a flow declaration, the type of flow isindicated by the flow_type value, in this case “repair”, the flowidentifier for this flow is indicated by the FLID value, in this case“20”, the repair type is indicated by the repair_type value, in thiscase “synchronized”, and the source flows protected by this repair floware indicated by the source_FLIDs values, in this case the source flowwith FLID “5.”

In an embodiment, the FEC OTI may include the FEC Encoding ID=6, whichcorresponds to the RaptorQ code specified in IETF RFC 6330, Al=8, whichindicates that 8-byte alignment is used, T=1280, which indicates symbolsare 1280 bytes in size, Z=1 and N=1, which indicates that the FECtransport object includes one source block and one sub-block per sourceblock (i.e., sub-blocking is not used). For repair flow declarations,the repair_type and the source_FLIDs values may be provided, as well asthe FEC OTI.

FIGS. 9A and 9B illustrate FEC encoding objects and repair packets thatcorrespond to the example repair flow declaration discussed above.

The top portion of FIG. 9A illustrates various data-fields that may beincluded in repair packets suitable for use in performing FEC thatcorresponds to the example repair flow declaration discussed above.Specifically, FIG. 9A illustrates that a Repair FLUTE Header 902 mayinclude an FLID field and an OSN field, that a Repair FEC Payload ID 904may include a TOL field and an ESI field, and that an FEC EncodingObject 906 may include an FEC transport object.

The repair packet header shown in 902 and 904 and the corresponding flowdeclaration shown above indicates that the repair packet carries repairsymbols generated from the FEC Encoding Object 906. In this example,since one source object is FEC protected by each FEC encoding, the FECEncoding Object 906 coincides with the FEC transport objectcorresponding to that source object when the number of source blocks Zand the number of sub-blocks N of the FEC Encoding Object 906 are bothone. The length of the FEC Encoding Object 906 is thirty-five (35)symbols, which corresponds to the value of the TOL field of the RepairFEC Payload ID 904. In this example, the repair symbol carried in thisrepair packet has ESI=37.

An example repair flow declaration that protects two synchronized sourceflows may be represented in a server or receiver device as follows:

flow_declararation{ flow_type = repair FLID = 21 repair_type =synchronized, source_FLIDs = 6, 7 FEC Encoding ID = 6, Al = 8, T = 1280,Z = 1, N = 1 }

In the above example of a flow declaration, the type of flow isindicated by the flow_type value, in this case “repair”, the flowidentifier for this flow is indicated by the FLID value, in this case“21”, the repair_type is indicated by the repair_type value, in thiscase “synchronized”, and the source flows protected by this repair floware indicated by the source_FLIDs values, in this case the source flowwith FLIDs “6” and “7”. The FEC OTI is the same as in the previousexample.

In various embodiments, to protect portions of a source object with anFEC repair, a templated TOI range may be provided as part of the FECrepair flow declaration. For example, this TOI range might identify thatrepair TOIs ten through nineteen protect source object 1 from the sourceflow, repair TOIs twenty through twenty-nine would protect source object2, etc. Below is an example of such an FEC repair flow declaration.

flow_declararation{ flow_type = repair FLID = 21 repair_type =synchronized, source_FLIDs = 6, 7 number_of_repair_TOIs_per_source_TOI =10 FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1 }

In the above example, there are ten (10) repair TOIs declared per sourceTOI. Repair TOIs 1-10 are reserved for protecting portions of the sourceobjects with TOI=1 from source flows with FLID=6 and FLID=7. Repair TOIs11-20 are reserved for protecting portions of the source objects withTOI=2 from source flows with FLID=6 and FLID=7. As such, in thisexample, up to ten (10) repair TOIs can be used to protect each pair ofsource objects from the two source flows with FLIDs 6 and 7. Note thatfor different pairs of source objects from the two source flows theremay be a different number of repair TOIs used up to the maximumallocated (10 in this example). That is, there may be only one (1)repair TOI used, e.g., repair TOI 30, for the pair of source objectswith source TOI=3. On the other hand, there may be ten (10) repair TOIsused, e.g., repair TOIs 40, 41, . . . , 49, for the pair of sourceobjects with source TOI=4. There may be zero (0) repair TOIs used forthe pair of source object with source TOI=5.

Thus, differing numbers of FEC protections of portions of the sourceobjects may be provided for different pairs of source objects. Further,two different FEC protections provided for the same pair of sourceobjects may protect non-overlapping portions of the source objects, oroverlapping portions of the source objects.

For example, the FEC protection associated with repair TOI 40 mayprovide bundled protection of the first half of the source object withTOI=4 and FLID=6, and the first half of the source object with TOI=4 andFLID=7. The FEC protection associated with repair TOI 41 may providebundled protection of the second half of the source object with TOI=4and FLID=6, and the second half of the source object with TOI=4 andFLID=7. The FEC protection associated with repair TOI 42 may providebundled protection of the middle half of the source object with TOI=4and FLID=6, and the middle half of the source object with TOI=4 andFLID=7.

In the above example, the TOI for each source object is not carried (oris not required to be carried) in the Repair FEC Payload ID 952 of eachrepair packet of the repair flow. This is because the source object TOImay be determined based on the templated TOI range carried in the FECrepair flow declaration, and the repair flow TOI carried in the RepairFEC Payload ID 952 of each repair packet.

The top portion of FIG. 9B illustrates various data-fields that may beincluded in repair packets suitable for use in performing FEC overportions of a source object. Specifically, FIG. 9B illustrates that aRepair FLUTE Header 902 may include an FLID field and an OSN field.Repair FEC Payload ID 952 may include a Start Byte Position (SBP) field,a transmission object length (TOL) field, and an ESI field. The TOL maybe the size (in symbols) of the transmission object of source symbols.

FIG. 9B also illustrates that an FEC Encoding Object 954 may include theportion of the source object that is to be protected, and the size inbytes of the portion of the source object that is to be protected (withpossibly some padding bytes between the portion of the source object andthe size). In the example shown, SBP=1500 and TOL=4 indicates that thepartial source object to be protected starts at byte position 1500within the source object. If the symbol size is 1000 bytes, then sincethe TOL=4 then the FEC protected portion of the source object is between3001 bytes and 3996 bytes in size. In this example, the partial sourceobject size is at most 3996 bytes, because there is a 4 byte field atthe end of the FEC Encoding Object to carry the partial source objectsize that is to be FEC protected, and thus the size of the partialsource object can be at most 1000*4−4=3996 bytes in size when the TOL=4and the symbol size is 1000 bytes. As such, the end byte position (whichis not explicitly signaled in this embodiment) is between 4500(1500+3001−1) and 5495 (1500+3996−1). Since the size (in bytes) of theprotected portion of the FEC Encoding Object 954 is carried at the endof the FEC Encoding Object 954, the actual end byte position may bedetermined after FEC decoding of the FEC Encoding Object 954. In theillustrated example, the size in bytes of the FEC Encoding Object 954 isshown as 3500, and the end byte position is 4999 (1500+3500−1) withinthe source object.

In another embodiment, the Repair FEC Payload ID 952 may include a StartByte Position (SBP) field and an End Byte Position (EBP) field for eachfull or partial source object protected, and an ESI field. For eachsource object that is to be protected, the FEC Encoding Object 954 mayinclude the portion of the source object that is to be protected.

The top portion of FIG. 10 illustrates various data-fields that may beincluded in repair packets suitable for use in performing FEC for twosynchronized source flows. The example illustrated in FIG. 10corresponds to the example repair flow declaration discussed above.

In the example illustrated in FIG. 10, the OSN field of the repair FLUTEHeader 902 is for two protected source flows, and the FEC EncodingObject 906 includes a concatenation of the FEC transport object havingFLID=6 and the FEC transport object having FLID=7 for an object havingOSN 4. The lengths of the FEC transport objects that are protected maybe identified by listing the TOLs of the two FEC transport objects inthe Repair FEC Payload ID 904 in the appropriate order (i.e., 18, 10),such as the order the objects are listed in the declaration.

An example repair flow declaration that protects two unsynchronizedsource flows may be represented in a server or receiver device asfollows:

flow_declararation{ flow_type = repair FLID = 22 repair_type =unsynchronized, source_FLIDs = 8, 9 FEC Encoding ID = 6, Al = 8, T =1280, Z = 1, N = 1 }

In the above example of a flow declaration, the type of flow isindicated by the flow_type value, in this case “repair.” The flowidentifier for this flow is indicated by the FLID value, in this case“22.” The repair type is indicated by the repair_type value, in thiscase “unsynchronized.” The source flows protected by this repair floware indicated by the source_FLIDs values, in this case the source flowwith FLIDs “8” and “9”. The FEC OTI is the same as in previous examples.

Different data-fields may be included in repair packets so that they aresuitable for use in performing FEC over portions of a source object. Forexample, the Repair FEC Payload ID 904 may include a start position(Start Pos) field and an end position (End Pos) field for each protectedportion that are suitable for use in identifying the symbol or byteranges for the protected portions of an object.

The top portion of FIG. 11 illustrates various data-fields that may beincluded in repair packets suitable for use in performing FEC for twounsynchronized source flows, and which corresponds to the example repairflow declaration that protects two unsynchronized source flows discussedabove. In the example illustrated in FIG. 11, the Repair FLUTE Header902 includes an OSN field (OSN1, OSN2) for each of the objects, namelythe objects identified in the repair flow declaration via the“source_FLIDs” field (i.e., objects having a FLID of 8 and 9).

Various embodiments may represent the object sequence number (OSN) in anobject sequence number indicator (OSNI) field or value, for eithersource flows or repair flows. The OSNI may be a short form for signalingthe OSN for synchronized or unsynchronized repair flow protection. TheOSNI may also be used to indicate whether or not an object is to be FECprotected in the current bundle of protected objects. That is, a zeroOSNI value may indicate that no source object is to be protected,whereas a non-zero OSNI value may indicate that a source object is to beprotected within the bundle.

Various embodiments may set the OSNI value to ((OSN modulo 255)+1) whenthere is a source object to protect. The mapping from an OSNI value toan OSN may be done based on a combination of the OSNI value and thestart and end transmission time information in the source flowdeclaration for the protected source flow.

As an example, suppose that the duration of transmission for each sourceobject of a source flow is two (2) seconds and the transmissions for thesource objects are consecutive in time. Further suppose that the totalduration of the transmission is 1401 seconds when a source packet withOSNI=191 is received. In this case, the possible OSN values that map toOSNI=191 include OSN=190, 445, 700, 955, 1210, etc. Yet, the sourceobject with OSN=190 is transmitted during the interval of time 380 to382 seconds, the source object with OSN=445 is transmitted during theinterval of time 890 to 892 seconds, the source object with OSN=700 istransmitted during the interval of time 1400 to 1402 seconds, the sourceobject with OSN=955 is transmitted during the interval of time 1910 to1912 seconds, and the source object with OSN=1210 is transmitted duringthe interval of time 2420 to 2422 seconds. As such, an embodimentreceiver device may determine, with a high degree of confidence, that asource packet with OSNI=191 received at 1401 seconds into thetransmission corresponds to OSN=700.

Note that in the above example, the receiver device may be incorrect inits assumption/determination when packets with other OSN values that mapto OSNI=191 are received at time 1401 seconds. However, this typicallyonly happens when packets are transmitted or received at least 500seconds earlier or later than advertised in the transmission timeinformation in the source flow declaration. For example, when packetsfrom the source object with OSN=445, which are meant to be transmittedbetween 890 and 892 seconds, are received at 1401 seconds, an embodimentreceiver device may determine that the packets arrived over 500 secondslater than their scheduled transmission time, and respond accordingly.

In an embodiment, the OSNI may be one (1) byte in length. This may meanthat the system may only use one byte of the FLUTE header per flow, asopposed to the three (3) bytes that may be required when using OSN, foreither source or repair flows. For repair flows, the OSNI may also allowthe system to signal that “no object” is to be protected, which may beaccomplished by setting the value of OSNI equal to zero (0). In thismanner, they system may support a variable number of protected sourceobjects. That is, the number of protected source objects may bevariable.

An example repair flow declaration that protects three unsynchronizedsource flows using OSNI instead of OSN (short form) may be representedin a server or receiver device as follows:

flow_declararation{ flow_type = repair FLID = 23 repair_type =unsynchronized short, source_FLIDs = 8, 8, 9 FEC Encoding ID = 6, Al =8, T = 1280, Z = 1, N = 1 }

In the above example of a flow declaration, the type of flow isindicated by the flow_type value, in this case “repair.” The flowidentifier for this flow is indicated by the FLID value, in this case“23.” The repair type is indicated by the repair_type value, in thiscase “unsynchronized short,” which indicates that unsynchronizedprotection using short OSNI fields (instead of the longer OSN fields inrepair packet headers). The source flows protected by this repair floware indicated by the source_FLIDs values, in this case the source flowwith FLIDs “8”, “8” and “9”. The FEC OTI is the same as in previousexamples.

The top portion of FIG. 12 illustrates various data-fields that may beincluded in repair packets suitable for use in performing FEC for threeunsynchronized source flows, and which corresponds to the example repairflow declaration discussed immediately above. In the example illustratedin FIG. 12, the Repair FLUTE Header 902 includes an OSNI field (OSNI1-3) for each of the objects. The values of the OSNI fields (OSNI 1-3)may be equal to ((OSN modulo 255)+1) of their corresponding three FECtransport objects. The FEC Encoding Object 906 protects two FECtransport objects with FLID=8 and one FEC transport object with FLID=9.

Suppose in this example that for the source flow with FLID=8 the sourcepackets for each subsequent source object are transmitted for two (2)non-overlapping seconds, that for the source flow with FLID=9 the sourcepackets for each subsequent source object are transmitted for 4non-overlapping seconds, and that the repair packets for the repair flowwith FLID=23 are transmitted over a similar interval of time duringwhich the source packets for the source objects that they protect aretransmitted. Further suppose that the repair packet with the headershown in the top portion of FIG. 12 is received at time 1401 seconds. Inthis case, an embodiment component may determine, with a high degree ofconfidence, that the source object of the source flow with FLID=8 thatcorresponds to OSNI=191 is the source object with OSN=700, that thesource object of the source flow with FLID=8 that corresponds toOSNI=192 is the source object with OSN=701, and that the source objectof the source flow with FLID=9 that corresponds to OSNI=96 is the sourceobject with OSN=350.

Various embodiments may include components configured to perform FECrecovery of source objects and/or portions of source objects. A receiverdevice may be configured to determine the source objects or portionsthat are protected by a received repair packet from the FLIDs (e.g., TSIfield value) of source flows listed in repair flow declaration for thatrepair packet, the OSNs in repair packet header of the repair packet,and/or from the range of source symbols from the protected sourceobject.

The receiver device may be configured to determine the range of symbolsfor the portions of protected objects from start and end position valuefields in the repair FEC payload ID 904 of the repair packet. Thereceiver device may determine the FEC transport object size (in symbols)for each of the protected source objects from the TOLs in the repair FECpayload ID 904 of the repair packet. In an embodiment, the receiverdevice may be configured to determine the size of the FEC EncodingObject 906 by summing the FEC transport object sizes. The receiverdevice may use the ESI carried in the repair FEC payload ID 904 of therepair packet to determine how the symbol (or symbols or portions ofsymbols) is generated from the FEC Encoding Object 906.

The receiver device may be configured to determine identity andplacement of source data into the FEC Encoding Object 906 from areceived source packet for one of the protected source objects. Forexample, the identity and placement of source data into the FEC EncodingObject 906 from a received source packet for one of the protected sourceobjects may be determined from the FLID and OSN received in the sourcepacket header, from the TOLs of the FEC transport objects, from thesymbol range, and from the byte offset in the source Payload ID of thesource packet. The FEC decoder of the receiver device may recover all orportions of an FEC Encoding Object 906 based on receiving in combinationenough source data of the FEC Encoding Object 906 (or portions of theobject) from source packets, byte or symbol range information, repairsymbols for the FEC Encoding Object 906 from repair packets, andproperly placed source packet data.

The receiver device may be configured to extract FEC transport objects(or portions thereof) from the FEC Encoding Object 906. The receiverdevice may extract the source objects (or portions) from the FECtransport objects based on the source object size field at the end ofeach FEC transport object and/or from the byte range information.

In an alternative embodiment, as opposed to using a byte range, thecomponents may be configured to use the source FEC Payload ID of anexisting FEC scheme. This embodiment may better support backwardcompatibility with existing FEC schemes, at least on the source deliverylevel. This embodiment may also support object bundling. For example,the Source FEC Payload ID may be converted to a byte range prior toperforming the FEC operations or applying the advanced FEC frameworkdiscussed in this application. This embodiment may further allowapplying the advanced FEC framework with arbitrary FEC schemes in asource protocol component, which is discussed in detail further below.

As another alternative, a component may be configured to signal thetransport source objects protected by a repair flow so as to avoidin-band signaling within repair packet headers. In particular, insteadof carrying a list of OSNs (or OSNIs) explicitly in repair packetheaders, the source object TOIs that are to be protected by a repairflow may be signaled using templating within the repair flowdeclaration.

The various embodiments may include components configured to performchunk delivery/reception with repair flows. On the broadcast side, aserver may send source objects in chunks as they become available,repair protected source objects that are sent after the source packetsfor those objects, and minimize its contribution to end-to-end delay. Onthe receiver side, a receiver device may recover source object as itarrives in chunks. The source object data may be made available to aclient application as it is received. The receiver device may playbackthe first source object playback only when repair is received forobject, even if no FEC decoding is needed. This prevents stalls in thefuture when FEC decoding is needed for subsequent source objects.Alternatively, FEC encoding may be applied to portions of sourceobjects, allowing FEC decoding of portions of source objects as theyarrive at the receiver device, and thus allowing more immediate playbackat the receiver device.

In an embodiment, the receiver device may be configured to beginplayback/rendering of the first source object immediately after a sourceobject is received. Subsequent packet loss that requires FEC decodingmay trigger a stall while waiting for the arrival of FEC repair.Advanced media playout systems may combine such FEC technologies byadjusting the playout rate of the media, for example by playing at alower video frame rate than the nominal or by using audio processing toextend the playout time.

In a further embodiment, the methods of packaging information intoobjects can be extended to provide transport of generic files and assetswithin MPEG Media Transport (MMT) for enhancing MMT to provide similarcapabilities and benefits and functionalities to those described abovethat enhance FLUTE/3GPP MBMS. This embodiment solves the problem ofdelivering a sequence of related files (e.g., a video or audio streamthat is partitioned into a sequence of files) that are to be deliveredover a network, typically in broadcast or multicast mode. A motivatingexample is delivering DASH segments, where each segment is a file of anaudio or video or multiplexed audio/video DASH representation.

There are existing solutions for delivering DASH segments via MBMS, butthese existing solutions lack the ability to indicate or signal that asequence of files are logically related and/or lack the ability tospecify a relationships between segments, files, objects, entities,streams, etc. As described above, we describe herein methods thatenhance MBMS with these abilities and signaling. The embodimentsdescribed herein can also provide new signaling, protocols, proceduresand methods that enhance the MPEG MMT suite of protocols towards thesame overall system architecture and methods that are described abovefor the FLUTE/3GPP MBMS suite of protocols, and also enhance the overallmethods and signaling operations described above.

In overview, this embodiment provides a solution for the delivery ofgeneric assets over MMT protocols. A generic asset may be one or morefiles that are logically grouped and share some commonality for anapplication, such as segments of a DASH Representation, a sequence ofMPUs, etc. The components may be configured to use a General FileDelivery Session (GFDS) to deliver a generic asset via the General FileDelivery (GFD) protocol.

A new data type for a generic asset or object may be defined for apayload that contains a generic object to be transported. Packetscarrying generic objects may have a generic payload header. Each filedelivered within a GFD session may be associated with transport deliveryinformation. This may include, but is not limited to, information suchas the transfer length and transfer coding. For transfer coding,different types may be defined that enable the delivery of files withoutin-band meta-information, files with in-band meta-information, and whichenable the progressive delivery of files with in-band meta-information.

Generally, the MMT protocol relies on existence and availability ofsession information at the receiver in order to interpret the protocolpackets. The session information may describe a flow and how objectsdelivered via the flow are to be interpreted and/or accessed by thereceiver device. In an embodiment, such session information may bedefined, included in, and/or delivered in one or more code points. Forexample, a code point may be used to signal that a packet or a sequenceof related objects conform to specific set of restrictions that aredefined in the code point. In these embodiments, a packet_id attributeand value may be used to accomplish the operations discussed above withreference to Flow ID (FLID). Thus, in the context of transportinggeneric files and assets within MMT, the packet_id may be the same as,or correspond to, the FLID attribute discussed above.

Embodiments may include components configured to assign to an object ora sequence of related objects information that is typically onlyavailable when delivering content via HTTP. The embodiments may includecomponents configured to assign the information to the object orsequence of objects, and deliver and use such information in anefficient manner. This may be accomplished by adding information that isstatic and the same for multiple objects into a code point that definesthe session information.

Briefly, a code point may define, include, or specify variousproperties, such as a file delivery mode and the maximum transfer lengthof any object delivered with this code point signaling. In addition, acode point may include any of the following information: the actualtransfer length of the objects; any information that may be present inthe entity-header; a Content-Location-Template using the TOI andpacket_id parameters (if present); and specific information on thecontent (e.g., how the content is packaged, etc).

There may be multiple classes of properties in a single session. In anembodiment, each code point may be generated to define a class ofproperties, and multiple code points may be used to communicate themultiple classes of properties for the session.

In an embodiment, each code point may be generated so as to be specificto a particular object in a sequence of related objects, or a particularsubsequence of the related objects. That is, each object in the sequenceof objects may refer to one code point. In an embodiment, the codepoints may be defined in a template file or similar data structure.

Embodiments may include components configured to signal multiple codepoints within one session. The components may generate an entity headerthat includes all the information and properties available in HTTP RFC2616, and additional or supplementary information, via the code points.The components may generate code points that include non-staticinformation, such as templates that include parameters that may beresolved (e.g., using TOI, etc.).

Embodiments may include components configured to deliver files in theGFD session may have to be provided to an application (e.g., CompositionInformation document, Media Presentation Description, etc.). The filemay be referenced through the URI provided or derived fromContent-Location, which may be provided either in-band or as part of thesession description. That is, there may be an application thatreferences the files, and including such information in the sessiondescription may allow for the establishment of a connection suitable fortransporting generic files and assets within MMT.

In an embodiment, a code point may define different ways to deliver afile or object. For example, an object may be a regular file that doesnot include any additional information (i.e., regular file mode). Theobject may be an entity that includes an entity header and a file (i.e.,regular entity mode). The object may be delivered as an entity header,file, and a trailer (i.e., progressive entity mode).

FIG. 13A illustrates an embodiment server method 1300 of communicatinginformation in a flow of objects over a broadcast or multicast network.In block 1302, a server processor of a server in the broadcast networkmay package the information into objects. In an embodiment, as part ofpackaging the information into objects in block 1302, the serverprocessor may package the information into variable size source packetsin optional block 1304. In an embodiment the server processor may, aspart of block 1302, package the information so that the objects do notinclude forward error correction semantics in optional block 1306. In anembodiment, as part of block 1302, the server processor may package theinformation into FLUTE objects in optional block 1308.

In block 1310, the server processor may send the objects in the flow ofobjects over the broadcast network without sending accompanying metadatafor each object in file delivery tables (FDTs). In an embodiment, aspart of block 1310, the server processor may send the objects as asequence of related objects in optional block 1312. In an embodiment, aspart of block 1310, the server processor may begin object transmissionsbefore all of the information is available in optional block 1314. In anembodiment, as part of block 1310, the server processor may send theobjects via FLUTE over the broadcast network in optional block 1316.

FIG. 13B illustrates an embodiment receiver device method 1350 ofreceiving information in a flow of objects over a broadcast or multicastnetwork and determining if the entire source object has been received orif at least some portion of the object is missing from the receivedsource packets. In block 1352, a device processor of a receiver devicemay receive source packets sent from the broadcast or multicast network.In determination block 1354, the device processor may determine if anyof the received source packets include a B-flag data-field having avalue of “1.”

When the device processor determines that the received source packetsinclude a B-flag data-field having a value of “1” (i.e., determinationblock 1354=“Yes”), in block 1356, the device processor may determinethat it has received the suffix of the object. In block 1358, the deviceprocessor may compute the size of the object by summing a byte offset inthe packet with the B-flag set to “1” and the packet payload size ofthat packet. In blocks 1360 and 1362, the device processor may determinewhether there are internal portions of the source object missing fromthe byte offsets and packet payload sizes of the received sourcepackets. When it is determined that there are not internal portionmissing from the received source packets (i.e., determination block1362=“No”), in block 1364, the device processor may render the contentand/or information included in the received source packets. When it isdetermined that there are internal portion missing from the receivedsource packets (i.e., determination block 1362=“Yes”), in optional block1366, the device processor may perform recovery operations, such aswaiting to receive additional the information, requesting that theinformation be re-sent, using received repair packets to FEC decode themissing portions of the source object, or processing the receivedpackets so as to present the content with a degraded quality.

When the device processor determines that the received source packets donot include a B-flag data-field having a value of “1” (i.e.,determination block 1354=“No”), in block 1368, the device processor maydetermine that at least some suffix of the object has not yet beenreceived. In optional determination block 1370, the device processor maydetermine if a timer has expired or another test condition has been metto indicate that there is a high probability that the suffix of theobject will not be received. If the device processor determines that thetimer has not expired or the other test conditions have not been met(optional determination block 1370=“No”), in block 1352, the deviceprocessor may wait to receive additional source packets.

When the device processor determines that the timer has expired oranother test condition has been met (optional determination block1370=“Yes”), in optional block 1366, the device processor may performany of a number of recovery operations, such as using received repairpackets to FEC decode the missing portions of the source object orrequesting that the information be re-sent or processing the receivedpackets so as to present the content with a degraded quality.

In various embodiments, the server and receiver components may beconfigured so that any or all of the above mentioned operations,methods, and solutions may be performed, accomplished, or implemented asextensions of existing technologies and/or structures.

FIGS. 14A-B illustrate logical and functional components in broadcastcommunication systems 1400, 1420 that are suitable for communicatingcontent in accordance with various embodiments. In each of thesebroadcast communication systems 1400, 1420, the operations forreceiving, packaging, FEC protecting, signaling and communicatinginformation are divided into separate and independent groups orcategories of operations, and each group or category of operations maybe performed by one or more hardware and/or software components (e.g.,server computing devices, etc.). Such grouping/organization may betterallow each of broadcast communication systems 1400, 1420 to bettersupport a variety of different protection schemes and deliverytechnologies, protocols, and standards.

FIG. 14A illustrates that the broadcast communication system 1400 may besplit or organized in two major groups: a source delivery protocol 1402and a forward error correction (FEC) framework 1404.Splitting/organizing the system 1400 in this manner allows for twoasynchronous layered coding (ALC) instantiations to be multiplexed orotherwise combined. This allows content to be delivered via a variety ofexisting technologies and/or structures, including existing FLUTEframeworks. This organization/grouping also allows the broadcastcommunication system 1400 provide a number of other enhancements andbenefits over existing broadcast solutions, including the featuresdiscussed herein.

In the example illustrated in FIG. 14A, the source delivery protocol1402 includes source ALC component 1406. The source ALC component 1406may be configured to include a source LCT and not require the use of FEC(no FEC). The forward error correction (FEC) framework 1404 may includean object bundling component 1414 and a repair ALC component 1408. Therepair ALC component 1408 may include a repair LCT and an FEC scheme.

The source delivery protocol 1402 encodes multimedia content in twocollections of files 1410 and 1412. Each collection 1410, 1412 mayinclude a group of related files. As an example, the first collection1410 may include video data files, and the second collection 1412 mayinclude audio data files. Each collection 1410, 1412 may or may not be aflow. Each collection 1410, 1412 may be assigned static metadata (StaticMetadata 1, Static Metadata 2). In the example illustrated in FIG. 14A,each file in the second collection is associated with dynamic metadata(DMD).

The system 1400 may be configured to treat each file in the system as anindividual object, and each file/object may be delivered through an ALCinstantiation.

The source ALC component 1406 may be configured to deliver files,objects, flows, bundles or collections. The repair ALC component 1408may be configured to flexibly protect the files, objects, flows,bundles, or collections for FEC.

The system 1400 may define a new protocol handler for LCT/UDP thatidentifies the protocol. In an embodiment, the system 1400 may use acode point to identify different collections of objects and assignparameters.

The system 1400 may be configured to support sending byte ranges ofobjects out of order and the signaling for the transmission of theobjects in the session definition so that a client application (e.g., ina receiver device) may be informed of the objects and/or transmissionsin advance, possibly with a maximum interleaving depth. This allows thesystem 1400 to support formats for which the size of the object needs tobe added in the beginning of file. This also allows the content data ofthe object to be sent first, and the size field/header to be sent lateronce the header data is available by indicating a byte range number thatis smaller than earlier sent data of the same object. This allows areceiver device to reconstruct the object, with the header being addedat the specified byte range.

In an embodiment, the system 1400 may be configured to provide a startTOI, an end TOI, or both, which may be used to signal a restricted list.In further embodiments, a code point may refer to the static FDI in use,and an LCT time header may be used to synchronize server time and clientas well as for measuring end-to-end latency or jitter. A repair flow mayinclude a reference to the session description 1416 and code point,which may used to obtain detailed protection characteristics.

In an embodiment, the FEC framework component 1404 may be configured tosend only the repair packets. In an embodiment, the system 1400 may beconfigured to define an LCT extension header so as to enable sending thesize of the individual objects. In an embodiment, the system 1400 may beconfigured to define a super-object that is FEC protected.

FIG. 14B illustrates various components and information flows in anexample broadcast communication system 1420 configured to generate anFEC repair packet based on two collections (i.e., two related groups ofobjects), and deliver the objects to a receiver device independent ofthe FEC repair packet in accordance with various embodiments. In theexample illustrated in FIG. 14B, the broadcast communication system 1420is organized into a source protocol component 1424 and a repair protocolcomponent 1426. The repair protocol component 1406 includes a sourceobject creation component 1434, a repair ALC component 1436, an LCTcomponent 1438, and an FEC scheme component 1440. The source protocolcomponent 1424 includes a source packet creation component 1428 and aLCT component 1430, the combination of which may be configured todeliver objects (e.g., source/delivery objects) or flows/collections ofobjects. In an embodiment, the source packet creation component 1428and/or the LCT component 1430 may be an Asynchronous Layered Coding(ALC) instantiation.

The source protocol component 1424 may be configured to receive, use,package, and communicate source data 1442. The source protocol component1424 may communicate the source data 1442 via delivery objects orflows/collections of objects. Each delivery object may be an object thatis self-contained for the application, possibly in combination withinformation from static metadata, and the LCT header data oftransmission session/stream identifier (TSI) and transmission objectidentifier (TOI).

The source protocol component 1424 may be configured to receive and usesource data 1422 that includes a diverse set of informationunits/entities, each of which may have different characteristics orproperties. For example, the source protocol component 1424 may receiveand use source data 1402 that includes a combination of non-real-timeand real-time data, a single data file (e.g., gzipped file, etc.) thatis only accessible as a whole and includes sub-units (e.g., files) ofvarying sizes (e.g., between several kBytes up to GBytes), and/or acollection of data files that are individually accessible but onlyuseful together (e.g. objects of a web page, etc.). As further examples,the source data 1402 may include a large multimedia file that isavailable on the Broadcast Multicast Service Center (BMSC) as whole anddistributed without real-time constraints, a collection of timed mediasegments that are referenced by arbitrary URL names (e.g., onerepresentation in an HLS distribution), a collection of timed mediasegments that are referenced by a common URL pattern (e.g. arepresentation in a Media Presentation in DASH), a media segment that ispart of a media presentation, multiple media components that aredistributed jointly and played out jointly, or a media file that isgenerated gradually in the server and transmitted prior to the servergenerating the entire file. As another example, the source data 1402 mayinclude a media file that a receiver device may start rendering,playing, or consuming after receiving only a portion of the media file(e.g., an fragmented MP4 file, a DASH On-Demand format representation,etc.), but which is only made available as a whole to the server.

The source protocol component 1424 may be configured to use the sourcedata 1422 to generate collections of related objects (i.e., Collection 1and Collection 2). In the example illustrated in FIG. 14B, the sourceprotocol component 1424 generates a first collection (Collection 1) thatincludes three delivery objects (i.e., Delivery Objects 1-3) and staticmetadata (i.e., Static Metadata 1). The second collection (Collection 2)includes static metadata (i.e., Static Metadata 2) and three deliveryobjects (i.e., Delivery Objects 1′-3′) that are associated with dynamicmetadata (DMD).

In an embodiment, the source protocol component 1424 may be configuredto deliver session information as a download delivery session. Thedownload delivery session may be included in, or described by, a sessiondescription protocol (SDP) unit.

In an embodiment, the source protocol component 1424 may be configuredto signal an FEC scheme that describes the usage of the sessioninformation or source protocol. In an embodiment, the source protocolcomponent 1424 may be configured to signal the FEC scheme via thesession description protocol (SDP) unit.

In various embodiments, the source protocol component 1424 may beconfigured to generate, use, or communicate static and/or dynamic filedelivery descriptors (FDDs). The source protocol component 1424 maygenerate, use, or communicate one or more static FDD fragments for eachdownload delivery session. The source protocol component 1424 mayassociate one or more static FDD fragments with a single downloaddelivery session. Each FDD may be identified via a @tsi data-field valuethat is included the download delivery session of the SessionDescription Protocol (SDP) unit. In an embodiment, the source protocolcomponent 1424 may generate, use, or communicate the FDD so that itreplicates all functionalities of a File Delivery Table (FDT). In anembodiment, the source protocol component 1424 may be configured togenerate, use, or communicate the FDD so that it may be used to generatean equivalent of an FDT, such as by using the TOI and templates.

In various embodiments, the source protocol component 1424 may beconfigured to generate, use, and/or communicate a source flowdeclaration. The source flow declaration may be included in, andcommunicated via, the user service description (USD). In an embodiment,the USD may be generated to include metadata fragments. Each metadatafragment may include StaticFDD data-field that specifies the static filedelivery descriptor (FDD). Each StaticFDD data-field may also includevarious other data-fields, such as a @tsi data-field, a@objectDeliveryMode data-field, a @oufOfOrderSending data-field, a@expires data-field, a @complete data-field, a @contentType data-field,a @contentEncoding data-field, a CodePoint data-field, a Filedata-field, and a FileTemplate data-field. Each of these data-fields mayinclude information that may be used by the various embodimentcomponents to identify or determine various characteristics of thesource data, delivery objects or communications.

For example, the @oufOfOrderSending data-field may include informationthat may be used to determine whether the source data 1422 is sent outof order. The @objectDeliveryMode data-field may include informationthat may be used to identify an object delivery mode. The @tsidata-field may include a transmission session/stream identifier (TSI),or information that may be used to identify a transport session to whichthe static file delivery descriptor (FDD) is assigned to in the LCTheader. For example, the @tsi data-field may include a TSI thatidentifies the static FDD instance used to interpret the delivery objector collection of delivery objects. In addition, the @tsi data-field mayfurther include a unique identifier (within the scope of the session)for the delivery object or collection of delivery objects.

The CodePoint data-field of the StaticFDD data-field may includeinformation that identifies the code points that are used in the packetheader and/or identifies mappings to specific values. The CodePointdata-field may include various other data-fields, such as a @assignmentdata-field, a @schemeIDURI data-field, and a @value data-field. The@assignment data-field may include information that identifies the valueof the CP field (Code Point field) that is assigned to a code point. The@schemeIDURI data-field may include information that identifies a schemethat defines the code point. The @value data-field may includeinformation that identifies the value of the scheme that defines thecode point.

The File data-field of the StaticFDD data-field may include the same orsimilar information that is typically included in a “File element” whenusing existing FLUTE solutions. However, unlike the “File element” usedin existing solutions, the File data-field is not required to includeFEC parameters. In addition, the File data-field may include variousother data-fields, such as a @byteRange data-field. The @byteRangedata-field may include information that identifies a byte range of thefile that constitutes the delivery object. This byte range may beexpressed or formatted as a byte-range specific expression, or anexpression that identifies a contiguous range of bytes. Embodimentcomponents (e.g., a receiver device) may use this information todetermine whether the delivery object includes the entire file orportions of the file. For example, a component may determine that theentire file is the delivery object in response to determining that the@byteRange data-field is null, empty, or does not include a value.

The FileTemplate data-field of the StaticFDD data-field may includeinformation that may be used by embodiment components to identify a filetemplate, which may be included in the body of the delivery object orHTTP entity. The FileTemplate data-field may include various otherdata-fields, such as a @startTOI data-field and a @endTOI data-field.The @startTOI data-field may include information that may be used toidentify the first TOI that is delivered. The @endTOI data-field mayinclude information that identifies the last TOI that is delivered.

In the various embodiments, the source protocol component 1424 may beconfigured to describe all the files delivered in session. The sourceprotocol component 1424 may describe the files individually or via alist. The source protocol component 1424 may also include static fileinformation in a one-time static description (e.g., File DeliveryDescriptor), and use header fields to create dynamic information, suchas URL/URI information. The source protocol component 1424 may use thistechnique to describe an object, set of objects, or collection.Embodiment components may identify collections or groups of objectsusing any of the various techniques described herein. For example, theTSI value may scope a collection or group of objects, in which case theTOI and/or byte range may be used to identify a group of objects.

In the various embodiments, the source protocol component 1424 may beconfigured to use templates and templating techniques to signalrelationships between the locations, names, availability times, andother metadata associated with an object or collection to be delivered.Such templates and templating techniques may be used to providemechanism to derive URI for object, delivery time for object,relationship between FLID, OSN and URI, etc.

In an embodiment, the source protocol component 1424 may be configuredto include a FileTemplate element or data-field in the static FileDelivery Descriptor. The FileTemplate data-field may include identifiersthat may be replaced with substitution parameters, such as after theentire delivery object or file is received in the receiver device. Forexample, the FileTemplate data-field may include a $TSI$ identifier thatmay be substituted with the TSI of the corresponding LCT packet, and a$TOI$ identifier that may be substituted with the TOI of thecorresponding LCT packet.

In an embodiment, the source protocol component 1424 may be configuredto deliver objects or entities that include metainformation in the formof entity-header fields and content in the form of an entity-body (e.g.,the file, object, etc.). The source protocol component 1424 may includefile attributes in the same delivery object as the file itself, such asvia in-band delivery techniques and/or in a dynamic fashion. Forexample, the source protocol component 1424 may associate and deliverattributes such as Content-Location, Content-Size, Content-Range, etc.via the same delivery object that includes the corresponding file.

In the various embodiments, the source protocol component 1424 may beconfigured to operate in various file delivery table (FDT) communicationmodes, including an extended FDT mode. When operating in the extendedFDT mode, the source protocol component 1424 may use FDTs and FDTextensions to provide or communicate the information that is typicallyincluded in entity headers. The use of FDT extensions may allow thesource protocol component 1424 to signal HTTP extension headers andother HTTP capabilities via FLUTE.

The source protocol component 1424 may be configured to operate invarious file delivery modes, such as a File Mode, a Regular Entity Mode,a Progressive Entity Mode, a Redundant FDT mode, a Complementary FDTmode, and a Dynamic FDT mode. In an embodiment, the source protocolcomponent 1424 may be configured to identify file delivery mode via thestatic File Delivery Descriptor unit.

When operating in File Mode, the source protocol component 1424 maydeliver objects as regular files or byte ranges of files. That is, whenoperating in the regular file mode, each delivery object may represent afile or a byte range of a file (i.e., @byteRange is present). The sourceprotocol component 1424 may include all the information associated witha delivery object in a FDD, and all the attributes of the file or byterange may be delivered via the static FDD or static FDT.

The source protocol component 1424 may also operate in the RegularEntity Mode. In this mode, object delivery via LCT may be closely orcompletely aligned with existing HTTP delivery techniques that delivercontent via HTTP entities. As mentioned above, an HTTP entity includesentity-header and entity-body. As such, when operating in the RegularEntity Mode, the source protocol component 1424 may deliver objects asentities that include an entity-header and entity-body (i.e., the file).The delivery objects may be generated or communicated so that they startwith the entity-header. The delivery objects may be generated orcommunicated so that the message body includes a URL and a contentrange, which may be used to signal, communicate, or determine that thedelivery object is a byte range of an object/file, as opposed to a fullobject/file.

When operating in Regular Entity Mode, the source protocol component1424 delivers all the attributes of the file in the static file deliverydescriptor (FDD) or static file delivery table (FDT) that is applicableto the delivered file. In addition, the entity-header that is sent withthe file or byte range (e.g., in-band) may include additionalinformation for that file/byte range. When certain attributes arepresent in both the FDD and entity-header, then the values in theentity-header may overwrite the corresponding values in the static FDD.When the header contains a Content-Range in the entity-header, then thedelivery object may be determined to include a byte range of anobject/file, as opposed to a full object/file.

The source protocol component 1424 may also operate in the ProgressiveEntity Mode to accomplish the progressive delivery of files, similar tothat which may be accomplished via chunked transfer mode in HTTP/1.1.When operating in the Progressive Entity Mode, the source protocolcomponent 1424 may deliver objects as entities that include anentity-header, a file, and a trailer. The trailer that may containadditional header fields that enable the source protocol component 1424to deliver the object/file in a progressive fashion, i.e. it can bedelivered before the entire file is generated.

In various embodiments, the source protocol component 1424 may beconfigured to include the trailer in the code point or the entityheader. All the attributes in the static file delivery table (FDT) maybe applied to the delivered object/file. In addition, the sourceprotocol component 1424 may generate the entity-header to includeadditional information for the file. When certain attributes are presentin both locations (i.e., FDD and entity-header), the values in theentity-header may overwrite the corresponding values in the static FDD.

When operating in the Redundant FDT mode, the source protocol component1424 may generate and send the FDT with the object so that theinformation included in FDT is redundant to the information included inthe FDD. When operating in the Complementary FDT mode, the sourceprotocol component 1424 may generate and send the FDT with the object sothat the FDT includes additional information that may be useful for thereceiver device. When operating in the Dynamic FDT mode, the sourceprotocol component 1424 may generate and send the FDT with the object sothat the FDT includes essential additional information that may be usedby the receiver device.

The source protocol component 1424 may be configured to use LCTcommunication technologies and methodologies in specific ways so as toaccomplish object delivery via FLUTE, and support the various featuresand functions discussed in this application. For example, the sourceprotocol component 1424 may set the value of a congestion control header(defined in LCT/ALC) to zero (0), set the TSI in the LCT headeraccording to the delivery object collection applied by the packet (e.g.,via the @tsi data-field), set the code point in the LCT header based onthe value of an @codepoint data-field, set the first bit of the PSI tozero (0) to indicate a source packet, etc. The source protocol component1424 may also use a source FEC payload ID that specifies the startingaddress (e.g., in octets, bytes, etc.) of the delivery object. Suchinformation may be communicated via direct addressing (e.g., using 32 or64 bits), or by using the SBN, ESI, and symbol size (T) values.

The source protocol component 1424 may be configured to use a LCT headerEXT_TIME extension to communicate or signal various time values andevents. For example, the source protocol component 1424 may use theEXT_TIME extension as a “sender current time” field to signal thesender's current time. This information may used to synchronize clocksin the sender and receiver devices. As a further example, the sourceprotocol component 1424 may use the EXT_TIME extension as an “expectedresidual time” field to signal the expected remaining time for a currentobject. The source protocol component 1424 may also use the EXT_TIMEextension as an SLC flag (Session Last Change flag) to signal theaddition or removal of segments.

The source protocol component 1424 may be configured to send byte rangesor portions of a file/object out of order, before all of the file/objectis received or generated in the sender device. As such, the byte rangesof an object/file may not be sent sequentially. Rather, a later byterange may be sent before an earlier byte range. In such cases, thesource protocol component 1424 may use the @outOfOrderSending data-fieldto communicate to receiver device that sender device applies suchtechnology and/or that the byte ranges may be transmitted out of order.

Sending byte ranges or portions of a file/object out of order isespecially useful for data formats that require that the header data begenerated after the media is produced, such as formats that include thefile's size information in the header. For such formats, the sourceprotocol component 1424 may send the header to the receiver device aftertransmitting the data so that receiver device may receive and use suchheader information to determine the size of the data unit. Since thesize of the header field is typically known in advance, this may beaccomplished by the receiver device skipping the header portion when theobject is received, or by using any of the other techniques discussed inthis application. To support formats for which the size of the headerfield is variable, the source protocol component 1424 may pad the dataor communication. The source protocol component 1424 may also set or usea flag to communicate an interleaving depth in time (e.g. milliseconds),maximum data ranges, etc.

In the various embodiments, the system 1140 may be configured todistinguish the source and repair flows by their different UDP flows(i.e., carried on different IP/UDP port combination) and/or via theirSession Description Protocol (SDP) files. When the LCT packets are sentin the same UDP flow, the system 1140 may distinguish the source andrepair flows based on the transmission session/stream identifier (TSI)in the LCT header fields of the packets. When the LCT packets are sentin the same UDP flow and have the same TSI value, the system 1140 maydistinguish the source and repair flows/packets based on the program andsystem information (PSI) bit in the header of a packet. This may beparticularly useful when the system 1420 operates in, or is required tosupport, a backward-compatibility mode.

The repair protocol component 1426 may be configured to protect piecesof delivery objects, bundles of delivery objects, and/or bundles ofpieces of delivery objects for FEC. In addition, the repair protocolcomponent 1426 may be configured to accomplish the delivery of thedelivery objects or pieces thereof (i.e., as opposed to protectingpackets).

The repair protocol component 1426 may include an FEC scheme component1434 configured to define an FEC encoding scheme, FEC decoding scheme,and/or various other protocol fields and procedures for identifyingpacket payload data (i.e., in the context of the FEC scheme). In variousembodiments the FEC scheme component 1434, which may be implemented as,or configured to operate as, a functional layer above the transportlayer (e.g., UDP/IP multicast) component 1428.

The repair protocol component 1426 may also include a RepairAsynchronous Layered Coding (ALC) component 1438 configured to flexiblyprotect the delivery objects 1430 or collections of objects (e.g.,Collection 1, Collection 2). Further, each of the repair protocolcomponent 1426 and the source protocol component 1424 may include aLayered Coding Transport (LCT) component 1436. The packets may be LCTpackets.

The repair protocol component 1426 may be configured to generate one ormore FEC objects. Each FEC object may be a complete delivery object or acontiguous byte range of a delivery object. In various embodiments, therepair protocol component 1426 may be configured so that FEC protectionmay be applied to a single FEC object or a collection of FEC objects.The repair protocol component 1426 may be configured so that the TSI maybe used to scope the collection a collection of FEC objects. The repairprotocol component 1426 may be configured to instantiate the TOI/TSIindependent of the FEC structure and/or using any of the techniquesdiscussed in this application.

In the various embodiments, the repair protocol component 1426 may beconfigured so that FEC-related information is communicated only when itdetermined that such information is needed, required, and/or useful. Therepair protocol component 1426 may also be configured to communicateFEC-related information so that receiver devices that not capable ofperforming FEC operations can ignore the FEC-related information andstill render its corresponding content. The repair protocol component1426 may be configured to perform symbol-based FEC operations, with afixed symbol size for each protected repair flow. The repair protocolcomponent 1426 may also be configured to perform the FEC operations sothat each repair flow provides protection for a delivery object from oneor more source flows.

The repair protocol component 1426 may be an FEC Framework that includesor is configured to communicate, an FEC repair flow declaration thatincludes all FEC specific information, an FEC object that is a protectedcontiguous octet range of a source object or the source object itself,an FEC transport object that is the concatenation of an FEC object, anFEC super object that is the concatenation of one or more FEC transportobjects, FEC protocol and packet structure. The FEC transport object mayinclude padding octets and size information, which may be used to form asymbol-aligned chunk of data. The FEC super object may be used to bundleFEC transport objects for FEC protection.

FIG. 15 illustrates various structures, data-fields, communicationpackets, transformations and information flows in an embodiment FECFramework 1500 configured to generate a FEC repair packet 1502 based ontwo source objects 1504, 1506. The FEC Framework 1500 may be includedin, or implemented as part of, the repair protocol component 1426discussed above with reference to FIG. 14B. In an embodiment, the sourceobjects 1504, 1506 may be the same as the delivery objects discussedabove with reference to FIG. 14B.

In the example illustrated in FIG. 15, the FEC Framework 1500 generatesa first FEC object 1508 for the first source object 1504, and a secondFEC object 1510 for the second source object 1506. Each of the FECobjects 1508, 1510 may be a full source object or a consecutive octetrange of a source object. The FEC Framework 1500 may be configured togenerate the FEC objects 1508, 1510 using TSI and TOI of itscorresponding source object 1504, 1506 and/or an octet range of thesource object 1504, 1506, i.e. start octet within the source object1504, 1506 and number of octets of source object 1504, 1506 thatconstitutes the FEC object 1508, 1510 to be protected.

For each FEC object 1508, 1510, the FEC Framework 1500 may generate anFEC transport object 1512, 1514 that includes a concatenation of an FECobject 1508, 1510, padding octets (P) 1516, 1520, and the FEC objectsize (F) 1518, 1522. The padding octets (P) 1516, 1520 may be paddingdata that is included towards the end of the FEC transport object 1512,1514, between the source object 1504, 1506 and the FEC object size (F)1518, 1522. The FEC object size (F) 1518, 1522 values may be expressedin octets and/or communicated via a four (4) octet field. That is, theFEC object size (F) 1518, 1522 may be carried in the last four (4)octets of the FEC transport object 1512, 1514.

In various embodiments, the FEC Framework 1500 may be configured tocompute an FEC transport object size (S) for each of the FEC transportobjects 1512, 1514 based on session information and/or the repair packetheaders. The FEC Framework 1500 may compute the FEC transport objectsize (S) in units of symbols and/or as an integer multiple of the symbolsize (T). For example, if the FEC object size (F) 1518, 1522 is the sizeof the FEC object 1508, 1510 expressed in octets, F is the F octets ofdata of the source object 1504, 1506, the parameter “f” denotes the four(4) octets of data carrying the value of F in network octet order (highorder octet first), the FEC transport object size (S) is the size of theFEC transport object with S=ceil((F+4)/T, the padding octets (P) 1516,1520 are S*T-4-F zero octets of data, and O is a concatenation of F, Pand f, then O constitutes the FEC transport object of size S*T octets.

It should be understood that the padding octets (P) 1516, 1520 and theFEC object sizes (F) 1518, 1522 are not required to be sent in sourcepackets of the source objects 1504, 1506. Rather, they may be includedin FEC transport object 1512, 1514 that FEC decoding recovers to extractthe FEC object 1508, 1510, and thus the source object 1504, 1506 orportion of the source object 1504, 1506 that constitutes the FEC object1508, 1510.

The FEC Framework 1500 may be configured to communicate generalinformation about an FEC transport object 1512, 1514 to the receiverdevice. The FEC Framework 1500 may be configured so that the generalinformation about an FEC transport object 1512, 1514 that is conveyed toan FEC enabled receiver device is the source TSI, source TOI, and theassociated octet range within the source object 1504, 1506 of theassociated FEC object 1508, 1510. Since the size in octets of the FECobject 1508, 1510 may provided in an appended field within the FECtransport object 1512, 1514, the remaining information may be conveyedas the TSI and TOI of the source object 1504, 1506 from which the FECobject 1508, 1510 associated with the FEC transport object 1512, 1514 isgenerated, the start octet within source object 1504, 1506 for theassociated FEC object 1508, 1510, and the size in symbols of the FECtransport object 1512, 1514.

The FEC Framework 1500 may be configured to generate an FEC super-object1540 based on the FEC transport objects 1512, 1514 and/or FEC repairflow declaration. For example, the FEC Framework 1500 may generate theFEC super-object 1540 to include a concatenation of the FEC transportobject 1512 and FEC transport object 1514. The FEC Framework 1500 mayalso generate the FEC super-object 1540 to include all the generalinformation about the FEC transport objects 1512, 1514 described above,as well as information identifying the order of the FEC transportobjects 1512, 1514 within the FEC super-object 1540.

In an embodiment, the FEC Framework 1500 may be configured to determinethe number of source symbols in the FEC super-object 1540. For example,if N is the total number of FEC transport objects for the FECsuper-object construction, S[i] is the size in symbols of FEC transportobject i for i=0, . . . , N−1, and B is the FEC super-object 1540 thatinclude a concatenation of the FEC transport object 1512, 1514 objectsin order, then the FEC super-object 1540 may be determined to includeK=sum (i=0) (N−1) S[i] source symbols.

The FEC Framework 1500 may be configured to generate the FECsuper-object 1540 to include additional general information beyond thegeneral information carried in the FEC transport objects 1512, 1514.Such information may include the total number of FEC transport objectsN. This information may also include values for each FEC transportobject 1512, 1514, such as the TSI and TOI of the source object 1504,1506 from which the FEC object 1508, 1510 associated with the FECtransport object 1512, 1514 is generated, a start octet within sourceobject 1504, 1506 for the associated FEC object 1508, 1510, and a sizein symbols of the FEC transport object 1512, 1514.

In an embodiment, the FEC Framework 1500 may be configured to generatethe FEC repair packet 1502 based on the FEC super-object 1540. The FECrepair packet 1502 may be generated based on Asynchronous Layered Coding(ALC), the LCT Layered Coding Transport (LCT) Building Block, and/or toinclude any of the technologies, features, and modifications discussedin this application. For example, the TSI in the LCT header may be setaccording to the repair flow to which the FEC repair packet 1502applies, which may be defined via the RepairFlow.SDPParameter@tsiattribute. The first bit of the SPI (Source Packet Indicator) may be setto 0 to indicate that it is a repair packet. The FEC configurationinformation may be carried in LCT extension headers.

As further examples, the FEC Framework 1500 may be configured to use anFEC building block to deliver only repair packets. Each repair packetwithin the scope of the repair flow (as indicated by the TSI field inthe LCT header) may be generated to include/carry the appropriate repairTOI, which may be unique for each FEC super-object that is createdwithin the scope of the TSI. The Session description information may becommunicated through SDP parameters, such as via the SDPParameterdiscussed above.

The FEC Framework 1500 may be configured to communicate summary FECinformation to the receiver device. In various embodiments, the FECFramework 1500 may be configured to communicate the summary FECinformation statically in the RepairFlow declaration, dynamically in anLCT extension header, or a combination thereof. The FEC Framework 1500may communicate such information for each super-object (identified by aunique TOI within a Repair Flow and associated to a Repair Flow by theTSI in the LCT header). Such information may include FEC configurationinformation, an FEC encoding ID, an FEC OTI, and additional FECinformation. This information may also include the total number of FECobjects included in the FEC super-object 1540, as well as the TSI andTOI of the source object 1504, 1506 from which the FEC object 1508, 1510associated with the FEC transport object 1512, 1514 is generated, astart octet within source object 1504, 1506 for the associated FECobject 1508, 1510, and a size in symbols of the FEC transport object1512, 1514.

The FEC Framework 1500 may be configured to generate, use, and/orcommunicate a FEC repair flow declaration that includes include FECsignaling information. For example, in MBMS User Services, a repair flowdeclaration may be included as a fragment of a bundle description or ause service description. As part of this repair flow declaration, theFEC Framework 1500 may provide a repair flow identifier for the repairflow in the @tsi attribute, with all the repair flows declared to be oftype RepairFlow. The combination of the IP address, the port and therepair flow identifier may provide a unique identifier amongst all flowswithin a user service. Note that an IP/port combination may carrydifferent FEC repair data as well as source data. In this case, the datamay be differentiated by the different TSI values in the LCT header.

In an embodiment, the FEC Framework 1500 may be configured to generatethe repair flow declaration to include information that identifies apattern of source objects (or octet ranges of source object) from sourceflows that are to be protected by the repair flow. In furtherembodiments, the FEC Framework 1500 may generate the repair flowdeclaration to include metadata fragments that include RepairFlowdata-field that defines a repair flow in session. Each RepairFlowdata-field may also include various other data-fields, such as a @tsidata-field, a @sessionDescription data-field, and a FECParametersdata-field. The @tsi data-field may include information that may be usedto identify the TSI to which the repair flow is assigned to in the LCTheader in the session. The @sessionDescription data-field may includeinformation that may be used to reference to the session descriptionthat contains the Repair Flow.

The FECParameters data-field may include various other data-fields, suchas an @fecEncodingId data-field, an @maximumDelay data-field, FECOTIdata-field, and ProtectedObject data-field. The @fecEncodingIddata-field may include information that may used to identify the appliedFEC scheme. The @maximumDelay data-field may include information thatmay used to identify the maximum delivery delay between any sourcepacket in the source flow and the repair flow. The FECOTI data-field mayinclude FEC Object Transmission Information (FEC OTI) that correspondsto FEC related information associated with an object as well as FECinformation associated with the encoding symbols of the object is to beincluded within this declaration and applies to all repair packets withthe repair flow.

The ProtectedObject data-field may include information that may be usedto identify the source flows that are protected by the Repair Flow andthe details on how the protection is done. Embodiment components may usesuch information to determine whether the source flow is contained inthe same session as the repair flow, the source flow is signaled withthe same TSI as the repair flow, the source TOI is the same as therepair TOI, etc. Embodiment components may determine that the packetsmay be differentiated via the PSI flag in the LCT header in response todetermining that the source TOI is the same as the repair TOI.Embodiment components may also use the information in theProtectedObject data-field to determine whether the size of each FECtransport object may be obtained from the repair packets using theEXT_TOL header.

The ProtectedObject data-field may include information that may be usedto identify the source objects in a collection of objects that areincluded in a repair flow. The ProtectedObject data-field may alsoinclude various other data-fields, such as an @sessionDescriptiondata-field, an @tsi data-field, an @sourceTOI data-field, an@fecTransportObjectSize data-field, and an @startOctet data-field.

The @sessionDescription data-field may include information that may beused to identify session description that contains the Source Flow. Anembodiment component may be configured to determine that the source flowis contained in the same session as the repair flow in response todetermining that the @sessionDescription data-field is empty.

The @tsi data-field may include information that may be used to identifya transport session identifier for the source flow to be protected. Anembodiment component may be configured to determine that the source flowis signaled with the same tsi/TSI as the repair flow in response todetermining that the @tsi data-field is empty, in which case the packetsmay be differentiated via the SPI flag (Source Packet Indicator flag) inthe LCT header, as defined in ALC IETF RFC 5775.

The @sourceTOI data-field may include information that may be used toidentify the TOI of the source object and a mapping of the TOI includedin the repair flow. An embodiment component may be configured todetermine that the source TOI is the same as the repair TOI in responseto determining that @sourceTOI data-field is empty.

The @fecTransportObjectSize data-field may include information that maybe used to identify the default size of each FEC transport object, suchas in units of symbols. An embodiment component may be configured todetermine that the default size values may be provided in the repairpackets using the EXT_TOL header in response to determining that@fecTransportObjectSize data-field is empty.

The @startOctet data-field may include information that may be used toidentify the start octet in the associated source object. An embodimentcomponent may be configured to determine that the start octetinformation may be included in the repair packets using the EXT_TOLheader in response to determining that @startOctet data-field is empty.The embodiment component may also be configured to determine thatEXT_TOL header will not be present in response to determining that the@startOctet data-field includes a value or is not empty.

In an embodiment, a component (e.g., receiver device) may be configuredto determine that @sourceTOI attribute specifies a mapping of the repairTOI value contained in a repair packet to a source TOI of a sourceobject that the repair packet protects in response to determining thatthe repair flow declaration includes a ProtectedObject data-field value.The mapping may be described through an equation, in C format, where theTOI field of the repair flow is specified as the variable TOI. Thecomponent may use the result of applying this equation to determine thesource TOI. The value of the attribute may be a proper C equation withat most one variable TOI and without the addition of the “;” sign. Thecomponent may be further configured to apply a default equation (e.g.,sourceTOI=“TOI”) in response to determining that there is no @sourceTOIdata-field value included in the ProtectedObject data-field.

An example repair flow declaration for a repair packet with TSI value 10and value TOI 20 that protects a source object with a TOI value 20 fromthe source flow with TSI value 1 may be represented in a server orreceiver device as follows:

<RepairFlow xmlns:xsi=“http://www.w3.org/2001/XMLSchema- instance”xmlns=“urn:3gpp:mbms:schema:repairflow:2013”xsi:schemaLocation=“urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd”tsi=“10” sessionDescription=“http://mbmsrocks.com/example-session1.sdp”> <FECParameters fecEncodingID=“6” maximumDelay=“5000”><FECOTI>XXXYYYYZZZZ</FECOTI> <ProtectedObject tsi=“1”sessionDescription=“http://mbmsrocks.com/example- session1.sdp”sourceTOI=“TOI” fecTransportObjectSize=“892”/> </FECParameters></RepairFlow>

An example repair flow declaration that does not include a @sourceTOIvalue is as follows:

<RepairFlow xmlns:xsi=“http://www.w3.org/2001/XMLSchema- instance”xmlns=“urn:3gpp:mbms:schema:repairflow:2013”xsi:schemaLocation=“urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd”tsi=“11” sessionDescription=“http://mbmsrocks.com/example-session1.sdp”> <FECParameters fecEncodingID=“6” maximumDelay=“5000”><FECOTI>XXXYYYYZZZZ</FECOTI> <ProtectedObject tsi=“2”fecTransportObjectSize=“892”/> <ProtectedObject tsi=“3”fecTransportObjectSize=“1340”/> </FECParameters> </RepairFlow>

In the above, example, since no @sourceTOI attribute is provided in theProtectedObject, the default equation sourceTOI=“TOI” is used to derivethe source TOI from the TOI. Thus, the super-object that is protected bya repair packet with TSI 11 and TOI 20 is the concatenation of the FECtransport object for the source object with TSI 2 and TOI 20 and the FECtransport object for the source object with TSI 3 and TOI 20. The FECtransport object size in both cases is defined and the FEC super-objecthas a total size of 2232 symbols.

An example repair flow declaration for FEC super-object that isprotected by a repair packet with TSI 12 and TOI 20 is the concatenationof the FEC transport object for the source object with TSI 4 and TOI 40,the FEC transport object for the source object with TSI 5 and TOI 20 andthe FEC transport object for the source object with TSI 4 and TOI 41 maybe represented in a server or receiver device as follows:

<RepairFlow xmlns:xsi=“http://www.w3.org/2001/XMLSchema- instance”xmlns=“urn:3gpp:mbms:schema:repairflow:2013”xsi:schemaLocation=“urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd”tsi=“12” sessionDescription=“http://mbmsrocks.com/example-session1.sdp”> <FECParameters fecEncodingID=“6” maximumDelay=“5000”><FECOTI>XXXYYYYZZZZ</FECOTI> <ProtectedObject tsi=“4”sourceTOI=“2*TOI”/> <ProtectedObject tsi=“5”/> <ProtectedObject tsi=“4”sourceTOI=“2*TOI+1”/> </FECParameters> </RepairFlow>

In the above example, the FEC transport object sizes of the sourceobjects are not included in the repair flow declaration. In addition,the sequence of the ProtectedObject declarations within a RepairFlowdeclaration may be used to determine the order of the FEC transportobjects for the source objects in the super-object.

An example repair flow declaration for a repair packet with TSI 13 andTOI 20 protects the source object with TSI 6 and TOI 21 may berepresented in a server or receiver device as follows:

<RepairFlow xmlns:xsi=“http://www.w3.org/2001/XMLSchema- instance”xmlns=“urn:3gpp:mbms:schema:repairflow:2013”xsi:schemaLocation=“urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd”tsi=“13” sessionDescription=“http://mbmsrocks.com/example-session1.sdp”> <FECParameters fecEncodingID=“6” maximumDelay=“5000”><FECOTI>XXXYYYYZZZZ</FECOTI> <ProtectedObject tsi=“6”sourceTOI=“TOI+1”/> </FECParameters> </RepairFlow>

An example repair flow declaration for a repair packet with TSI 14 andTOI 10 protects the concatenation of the FEC transport objects for twosource objects: the source object with TSI 7 and TOI 20 and the sourceobject with TSI 7 and TOI 21 may be represented in a server or receiverdevice as follows:

<RepairFlow xmlns:xsi=“http://www.w3.org/2001/XMLSchema- instance”xmlns=“urn:3gpp:mbms:schema:repairflow:2013”xsi:schemaLocation=“urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd”tsi=“14” sessionDescription=“http://mbmsrocks.com/example-session1.sdp”> <FECParameters fecEncodingID=“6” maximumDelay=“5000”><FECOTI>XXXYYYYZZZZ</FECOTI> <ProtectedObject tsi=“7”repairTOI=“2*TOI”/> <ProtectedObject tsi=“7” repairTOI=“2*TOI+1”/></FECParameters> </RepairFlow>

In the above example, a repair flow declaration with TSI 14 provides thestatic FDD. In addition, the ordering of the FEC transport objects inthe FEC super-object is the same as the order in which theProtectedObject declarations are made in the Repairflow declaration.Thus, the FEC super-object corresponding to a repair packet with TSI 14and TOI 10 is the concatenation of the FEC transport object for thesource object with TSI 7 and TOI 20 and the FEC transport object for thesource object with TSI 7 and TOI 21

In summary, the foregoing embodiments include methods that may beimplemented in broadcasters and receiver devices for communicatinginformation via a broadcast network that includes associating acollection of related source objects with a source flow, andtransmitting the collection of related source objects over the broadcastnetwork associated with the source flow so that the source objects maybe received and recovered by a receiver device based on theirrelationship to each other. In an embodiment, a source flow identifier(e.g., FLID) identifying the source flow may be determined, and eachpacket carrying data for one or more of the source objects of therelated source objects associated with the source flow may carry thesource flow identifier. In an embodiment, the data of a source objectcarried in a packet may be identified by a byte range carried in thepacket. In an embodiment, the source flow identifier may be carried inthe Transmission Session Identifier (TSI) field. In an embodiment, thesource flow identifier may be carried in the combination of IPdestination address field and the UDP port number field. In anembodiment, the source flow identifier may be carried in the codepoint(CP) field.

In an embodiment, a collection of source object identifiers may bedetermined, each packet carrying data for one of the related sourceobjects of the source flow may carry a source object identifier, and thecombination of the source flow identifier and source object identifiermay identify the source object from the collection of related sourceobjects associated with the source flow for which the packet carriesdata. In an embodiment, the source object identifiers may beTransmission Object Identifiers (TOIs). In an embodiment, the sourceobject identifiers may be Object Sequence Numbers (OSNs).

In an embodiment, more than one collection of related source objects maybe transmitted over the broadcast network, each collection of relatedsource objects may be associated with a different source flow, thesource flow identifier identifying each of the source flows may beunique, and the source flow of each packet carrying data may beassociated with and may be identified by the source flow identifiercarried in the packet.

In an embodiment, portions of the source flow identifier may be carriedwithin different fields within a packet. In an embodiment, at least someof the source objects may include a byte range of a file, and at leastsome of the source objects may include an HTTP header and a byte rangeof a file. In an embodiment, a URL may be associated with a file, andthe source object can be referenced with the URL for the file and acorresponding byte range. In an embodiment, at least some of the sourceobjects may include a file, and a URL may be associated with the file sothat the source object can be referenced with the URL for the file.

In an embodiment, at least some of the source objects may include anHTTP header and an associated file. In an embodiment, at least some ofthe source objects may include an HTTP header, an associated file, andan HTTP trailer.

Further embodiments include methods that may be implemented inbroadcasters and receiver devices for transmitting information via abroadcast network that includes receiving portions of an entire file,generating the source objects based on the received portions prior toreceiving the entire file, and transmitting the generated source objectsto the receiver device prior to receiving the entire file. In anembodiment, transmitting the generated source objects to the receiverdevice prior to receiving the entire file may include transmitting thedata for a source object in a different order than an order than thedata order of the file. In an embodiment, the file may include a filesize at the beginning of the file, and the data for a source object maybe transmitted in an order such that at least some data of the fileafter the file size may be transmitted before the file size. In anembodiment, a source object may include an HTTP header and an associatedfile. In an embodiment, a source object may include an HTTP header, anassociated file and an HTTP trailer.

In an embodiment, methods may further include determining source flowmetadata for a collection of source objects associated with a sourceflow, in which the source flow metadata signals relationships betweenthe locations, names, availability times, or other metadata for thecollection of source objects associated with a source flow. In anembodiment, templates may be used to signal at least some of therelationship information in the source flow metadata. In an embodiment,portions of the source flow metadata for a source flow may be providedto the receiver device in advance of when at least some of the relatedsource objects associated with the source flow are transmitted. In anembodiment, portions of the source flow metadata provided to thereceiver device may include timing information, uniform resourceidentifier (URI), and information identifying decryption keys for thesource objects. In an embodiment, providing portions of the source flowmetadata to the receiver device may include sending portions of the flowmetadata out-of-band to the receiver device in advance of transmittingat least some of the source objects associated with the source flow, andsending other portions of the source flow metadata in-band with thesource objects. In an embodiment, the portions of the source flowmetadata sent in-band with each source object may include an indicationof the last portion of data of the source object. In an embodiment,providing portions of the source flow metadata to the receiver devicemay include sending portions of the source flow metadata via aunidirectional transport protocol without sending a file delivery table.In an embodiment, transmitting the collection of related source objectsmay include transmitting the collection of related source objects viamultimedia broadcast multicast services (MBMS).

In an embodiment, transmitting the collection of related source objectsmay include transmitting the collection of related source objects viafile delivery over unidirectional transport (FLUTE). In an embodiment,transmitting the collection of related source objects may includetransmitting the source objects independent of their correspondingrepair objects. In an embodiment, the methods may further include usingsession description protocol (SDP) information to distinguish a sourceobject from its corresponding repair object. In an embodiment,transmitting the collection of related source objects may includetransmitting the source objects without transmitting forward errorcorrection (FEC) signaling information.

In an embodiment, methods may further include transmitting FEC repairdata for a collection of related source objects associated with a sourceflow over the broadcast network so that the source objects may bereceived and decoded by a receiver device based on their relationship toeach other, each packet carrying FEC repair data for one or more of therelated source objects associated with the source flow may carry thesource flow identifier identifying the source flow for which the packetcarries FEC repair data, each packet carrying FEC repair data for one ormore of the related source objects associated with the source flow maycarry the one or more source object identifiers of the one or moresource objects from which the FEC repair data carried in the packet maybe generated, and the combination of the source flow identifier and theone or more source object identifiers may identify the one or moresource objects from the collection of related source objects associatedwith the source flow from which the FEC repair data carried in thepacket may be generated.

In an embodiment, the methods may further include transmitting thepackets carrying FEC repair data generated from one or more sourceobjects largely within the same interval of time that the packetscarrying data for the one or more source objects are transmitted.

In an embodiment, the methods may further include associating a repairflow with one or more source flows, determining a repair flow identifierfor the repair flow, carrying the repair flow identifier in each packetcarrying FEC repair data associated with the repair flow, determining acollection of repair object identifiers for the repair flow, andcarrying a repair object identifier from the collection of repair objectidentifiers in each packet carrying FEC repair data associated with therepair flow, wherein which of the source objects from the collections ofrelated source objects of the one or more source flows associated withthe repair flow the FEC repair data carried in a packet is generated maybe determined at least in part by the combination of the repair flowidentifier and repair object identifier carried in the packet. In anembodiment, the repair flow identifier may be carried in theTransmission Session Identifier (TSI) field. In an embodiment, therepair flow identifier may be carried in the combination of IPdestination address field and the UDP port number field. In anembodiment, the repair flow identifier may be carried in the codepoint(CP) field. In an embodiment, the repair object identifiers areTransmission Object Identifiers (TOIs). In an embodiment, the repairobject identifiers are Object Sequence Numbers (OSNs).

In an embodiment, the methods may further include determining repairflow metadata for the repair flow, in which the repair flow metadatasignals relationships between the repair object identifier carried in apacket carrying FEC repair data and the source objects from the one ormore collections of related source objects associated with source flowsfrom which the FEC repair data in the packet is generated. In anembodiment, templates may be used to signal at least some of therelationship information in the repair flow metadata. In an embodiment,portions of the repair flow metadata for a repair flow may be providedto the receiver device in advance of when at least some of the relatedsource objects associated with the source flows associated with therepair flow are transmitted.

In an embodiment, the methods may include transmitting the packetscarrying FEC repair data generated from one or more source objectslargely within the same interval of time that the packets carrying datafor the one or more source objects are transmitted. In an embodiment,the FEC repair data carried in packets with a same repair flowidentifier and a same repair object identifier may be generated from twosource objects which are in different source flows, wherein the amountof data received in combination from packets with the same repair flowidentifier and the same repair object identifier and the two sourceobjects from which the FEC repair data in those packets is generatedthat is sufficient to decode the two source objects may be equal to orslightly more than the aggregate size of the two source objects. In anembodiment, portions of the repair flow identifier may be carried withindifferent fields within a packet.

FIG. 16 is a system block diagram of a mobile computing device suitablefor use as a receiver device with any of the embodiments. A typicalmobile computing device 1600 may include a processor 1601 coupled tointernal memory 1602, to a display 1603, and to a speaker 1604.Additionally, the mobile computing device 1600 will include an antenna1606 for sending and receiving electromagnetic radiation that may beconnected to a wireless data link and/or cellular telephone transceiver1608 coupled to the processor 1601 and a mobile multimedia broadcastreceiver 1610 coupled to the processor 1601. A mobile computing device1600 typically also includes menu selection buttons 1612 or rockerswitches for receiving user inputs.

The mobile computing device 1600 may also include a soundencoding/decoding (CODEC) circuit 1614 which digitizes sound receivedfrom a microphone into data packets suitable for wireless transmissionand decodes received sound data packets to generate analog signals thatare provided to the speaker 1604 to generate sound. Also, one or more ofthe processor 1601, wireless transceiver 1608 and CODEC circuit 1614 mayinclude a digital signal processor (DSP) circuit (not shown separately).

The various embodiments on the broadcast side may be implemented on anyof a variety of commercially available server devices, such as theserver 1700 illustrated in FIG. 17. Such a server 1700 typicallyincludes a processor 1701 coupled to volatile memory 1702 and a largecapacity nonvolatile memory, such as a disk drive 1703. The server 1700may also include a floppy disc drive, compact disc (CD) or DVD discdrive 1704 coupled to the processor 1701. The server 1700 may alsoinclude network access ports 1705 coupled to the processor 1701 forestablishing data connections with a network 1706, such as a local areanetwork coupled to other broadcast system computers and servers.

The processors 1701 may be any programmable microprocessor,microcomputer or multiple processor chip or chips that can be configuredby software instructions (applications) to perform a variety offunctions, including the functions of the various embodiments describedabove. In some mobile receiver devices, multiple processors may beprovided, such as one processor dedicated to wireless communicationfunctions and one processor dedicated to running other applications.Typically, software applications may be stored in the internal memory1702, before they are accessed and loaded into the processor 1601, 1602.The processor 1601, 1602 may include internal memory sufficient to storethe application software instructions.

Various embodiments may include methods of communicating informationover a broadcast network, which may include delivering files/objectsusing existing technologies, protocols and/or structures; deliveringfiles/objects in packets where each packet contains a continuous byterange of the file; delivering files/objects in packets where at leastone packet with a larger starting address for the byte range is sentprior to a packet with a smaller address for the byte range; defining anew protocol handler for LCT/UDP that identifies a communicationprotocol suitable for the delivery of files/objects; using a code pointto identify different collections of objects and assign parameters;using a session definition or session description message or componentto support the delivery of files/objects and the signaling of thedelivery; sending data of a file/object prior to sending the sizefield/header; using a start Transport Object Identifier (TOI) or an endTOI or both to signal a restricted list; using a code point to uniquelyidentify a static File Delivery Information (FDI) in use; using an LCTtime extension header for synchronizing server and client; using an LCTtime extension header for jitter or latency measurements; definingRepair Flow as a reference to the session description and code point andproviding the detailed protection characteristics; defining asuper-object so that it is FEC protected; using an FEC FRAMEWORK as anALC instantiation to send only repair packets; defining an LCT extensionheader that enables the sending of the size of the individual FECtransport objects; using existing fields to signal or support using aFlow identifier (FLID); using TOI to identify a transport object withoutother modifications to the signaling or protocols; using a static FDI tosignal flow declarations; signaling transport source objects protectedby a repair flow so as to avoid in-band signaling within repair packetheaders; and signaling source object TOIs that are to be protected by arepair flow using templating within the repair flow declaration.

The various embodiments may provide a number of enhancements andbenefits over existing broadcast solutions. Embodiments provide enhancedFile Delivery Over Unidirectional Transport (FLUTE)-based delivery of asequence of related objects. Embodiments provide capability toaccomplish flow object delivery; support for Dynamic Adaptive Streamingover HTTP (DASH) and other similar applications, standards, orprotocols; and capability to reduce the number of objects that arerequired to be received before content may be recovered from theobjects. Embodiments eliminate the need to deliver a file delivery table(FDT) for each object that is streamed/transmitted. Embodiments providesupport for the provisioning of information to FLUTE receivers inadvance, which may be accomplished before the objects are sent to orreceived by the FLUTE receivers. Embodiments improve delivery of timinginformation, uniform resource identifiers (URIs), and otheridentification information for objects in a flow. Embodiments supportimproved decision making and planning in receiver devices. Embodimentsprovide support for provisioning links to client applications.Embodiments support establishing and identifying relationships betweenobjects and DASH segments of a representation described in a MediaPresentation Description (MPD). Embodiments support chunkdelivery/reception of content. Embodiments enable reductions of senderend-to-end latency independent of usage of forward error correction(FEC) operations or capabilities of the receiver devices. Embodimentsenable reductions of receiver end-to-end latency when FEC is not used orrequired. Embodiments provide capability to wait or pause operationsuntil FEC use is deemed acceptable. Embodiments support generating,sending, and receiving variable sized source packets. Embodimentssupport aligning source packet boundaries with underlying mediastructure boundaries such as access units, network abstraction layerunits, samples, boxes of a file format or similar constructs.Embodiments support the delivery of source content with no FECsemantics; allowing receiver devices that do not have FEC capabilitiesto receive source content. Some embodiments support FEC object bundling;provide FEC protection over multiple objects; other embodiments provideFEC protection for portions of individual source objects; yet otherembodiments provide FEC protection of bundles of portions of individualsource objects. Embodiments enable delivering objects as complete HTTPGET responses, such as those defined in RFC 2616. Embodiments providecompatibility with, and support for the reuse of, current broadcast andFLUTE standards. Embodiments support the delivery of standard FLUTEobjects using FDTs in the same session with delivery of sequences ofrelated objects described herein without using FDTs. The variousembodiments may also include a number of additional benefits andenhancements that are discussed below.

Additional enhancements and benefits over existing broadcast solutionsprovided by the various embodiments may also include transport ofgeneric files and assets within MPEG Media Transport (MMT); use of codepoints; use of Hypertext Transfer Protocol (HTTP) headers as part of theobjects; templating; use of code points and signaling in the code pointsto deliver content specific aspects of a file; modification of the MMTprotocol include features suitable for signaling via code points;signaling an object transfer size via a trailer of the code point orentity header; delivering an object through a unidirectional protocol asa combination of an HTTP entity header and an HTTP entity body such thatthe object is suitable for use as a regularly delivered HTTP resource;delivering an object via chunk or sequential delivery; indicating theobject's size or other information relating to the object that is notknown at the start of the delivery by adding the size value or otherinformation as part of the object delivery in a trailer; signaling anobject size as part of a code point transfer; and delivering an objectvia an MPEG Media Transport (MMT) protocol such that the object to whichthe payload relates is identified by a packet_id attribute (whichidentifies the flow that the object belongs to) in a MMT protocol headerand the transmission object identifier (TOI) attribute carried in theGeneral File Delivery (GFD) protocol header (that identifies aparticular object within a flow of objects).

The foregoing method descriptions and the process flow diagrams areprovided merely as illustrative examples and are not intended to requireor imply that the steps of the various aspects must be performed in theorder presented. As will be appreciated by one of skill in the art theorder of steps in the foregoing aspects may be performed in any order.Words such as “thereafter,” “then,” “next,” etc. are not intended tolimit the order of the steps; these words are simply used to guide thereader through the description of the methods. Further, any reference toclaim elements in the singular, for example, using the articles “a,”“an” or “the” is not to be construed as limiting the element to thesingular.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the aspects disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

The hardware used to implement the various illustrative logics, logicalblocks, modules, and circuits described in connection with the aspectsdisclosed herein may be implemented or performed with a general purposeprocessor, a digital signal processor (DSP), an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA) orother programmable logic device, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A general-purpose processor maybe a multiprocessor, but, in the alternative, the processor may be anyconventional processor, controller, microcontroller, or state machine. Aprocessor may also be implemented as a combination of computing devices,e.g., a combination of a DSP and a multiprocessor, a plurality ofmultiprocessors, one or more multiprocessors in conjunction with a DSPcore, or any other such configuration. Alternatively, some steps ormethods may be performed by circuitry that is specific to a givenfunction.

In one or more exemplary aspects, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored as one or moreinstructions or code on a non-transitory computer-readable storagemedium, non-transitory computer-readable medium or non-transitoryprocessor-readable medium. The steps of a method or algorithm disclosedherein may be embodied in a processor-executable software module whichmay reside on a non-transitory computer-readable or processor-readablestorage medium. Non-transitory computer-readable or processor-readablestorage media may be any storage media that may be accessed by acomputer or a processor. By way of example but not limitation, suchnon-transitory computer-readable or processor-readable media may includeRAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othermedium that may be used to store desired program code in the form ofinstructions or data structures and that may be accessed by a computer.Disk and disc, as used herein, includes compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk, and blu-raydisc where disks usually reproduce data magnetically, while discsreproduce data optically with lasers.

Combinations of the above are also included within the scope ofnon-transitory computer-readable and processor-readable media.Additionally, the operations of a method or algorithm may reside as oneor any combination or set of codes and/or instructions on anon-transitory processor-readable medium and/or computer-readablemedium, which may be incorporated into a computer program product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the following claims and theprinciples and novel features disclosed herein.

What is claimed is:
 1. A method of communicating information via anetwork, comprising: receiving, in a receiver device, a packet includinga transport session identifier and a flow identifier for a single flowof a collection of related source objects via a unidirectional transporttransmission, wherein: the packet includes data of at least one sourceobject in the collection of related source objects; and the flowidentifier indicates an association of the collection of related sourceobjects with the single flow and the flow identifier is the same for allsource objects in the collection of related source objects.
 2. Themethod of claim 1, further comprising: recovering the collection ofrelated source objects based on the association of the related sourceobjects with the single flow.
 3. The method of claim 1, wherein theunidirectional transport transmission is a broadcast transmission. 4.The method of claim 3, wherein the network is a broadcast network. 5.The method of claim 1, wherein: the packet includes forward errorcorrection (FEC) repair data, a repair flow identifier, and a repairobject identifier; and a combination of the repair flow identifier andthe repair object identifier identify from which of the source objectsin the collection of related source objects the FEC repair data isgenerated.
 6. The method of claim 1, wherein at least one source objectin the collection of related source objects includes a byte range of afile.
 7. The method of claim 1, wherein at least one source object inthe collection of related source objects is a file.
 8. The method ofclaim 1, wherein at least one source object in the collection of relatedsource objects includes a hypertext transfer protocol (HTTP) header anda byte range of a file.
 9. A device, comprising: a processor configuredwith processor-executable instructions to perform operations comprising:receiving a packet including a transport session identifier and a flowidentifier for a single flow of a collection of related source objectsvia a unidirectional transport transmission in a network, wherein thepacket includes data of at least one source object in the collection ofrelated source objects, and wherein the flow identifier indicates anassociation of the collection of related source objects with the singleflow and the flow identifier is the same for all source objects in thecollection of related source objects.
 10. The device of claim 9, whereinthe processor is configured with processor-executable instructions toperform operations such that receiving the packet including a transportsession identifier and a flow identifier for a single flow of acollection of related source objects via a unidirectional transporttransmission in a network comprises receiving the packet from abroadcast transmission.
 11. The device of claim 10, wherein the networkis a broadcast network.
 12. The device of claim 9, wherein the processoris configured with processor-executable instructions to performoperations further comprising: recovering the collection of relatedsource objects based on the association of the related source objectswith the single flow.
 13. The device of claim 12, wherein the processoris configured with processor-executable instructions to performoperations such that recovering the collection of related source objectsbased on the association of the related source objects with the singleflow comprises recovering the collection of related source objectsusing: forward error correction (FEC) repair data, a repair flowidentifier, and a repair object identifier included in the packet,wherein a combination of the repair flow identifier and the repairobject identifier identify from which of the source objects in thecollection of related source objects the FEC repair data were generated.14. The device of claim 13, wherein at least one source object in thecollection of related source objects includes a byte range of a file.15. The device of claim 13, wherein at least one source object in thecollection of related source objects is a file.
 16. The device of claim13, wherein at least one source object in the collection of relatedsource objects includes a hypertext transfer protocol (HTTP) header anda byte range of a file.
 17. A non-transitory computer-readable storagemedium having stored thereon processor-executable software instructionsconfigured to cause a processor of a device to perform operationscomprising: receiving a packet including a transport session identifierand a flow identifier for a single flow of a collection of relatedsource objects via a unidirectional transport transmission in a network,wherein the packet includes data of at least one source object in thecollection of related source objects, and wherein the flow identifierindicates an association of the collection of related source objectswith the single flow and the flow identifier is the same for all sourceobjects in the collection of related source objects.
 18. Thenon-transitory computer-readable storage medium of claim 17, wherein theprocessor-executable software instructions are configured to cause aprocessor of a device to perform operations such that receiving thepacket including a transport session identifier and a flow identifierfor a single flow of a collection of related source objects via aunidirectional transport transmission in a network comprises receivingthe packet from a broadcast transmission.
 19. The non-transitorycomputer-readable storage medium of claim 18, wherein the network is abroadcast network.
 20. The non-transitory computer-readable storagemedium of claim 17, wherein the processor-executable softwareinstructions are configured to cause a processor of a device to performoperations further comprising: recovering the collection of relatedsource objects based on the association of the related source objectswith the single flow.
 21. The non-transitory computer-readable storagemedium of claim 20, wherein the processor-executable softwareinstructions are configured to cause a processor of a device to performoperations such that recovering the collection of related source objectsbased on the association of the related source objects with the singleflow comprises recovering the collection of related source objectsusing: forward error correction (FEC) repair data, a repair flowidentifier, and a repair object identifier included in the packet,wherein a combination of the repair flow identifier and the repairobject identifier identify from which of the source objects in thecollection of related source objects the FEC repair data were generated.22. The non-transitory computer-readable storage medium of claim 21,wherein at least one source object in the collection of related sourceobjects includes a byte range of a file.
 23. The non-transitorycomputer-readable storage medium of claim 21, wherein at least onesource object in the collection of related source objects is a file. 24.The non-transitory computer-readable storage medium of claim 21, whereinat least one source object in the collection of related source objectsincludes a hypertext transfer protocol (HTTP) header and a byte range ofa file.
 25. A device, comprising: means for receiving a packet includinga transport session identifier and a flow identifier for a single flowof a collection of related source objects via a unidirectional transporttransmission in a network, wherein the packet includes data of at leastone source object in the collection of related source objects, and theflow identifier indicates an association of the collection of relatedsource objects with the single flow and the flow identifier is the samefor all source objects in the collection of related source objects.